This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have code that does a bunch of file copy operations using FileUtil.copy(sourceFO.getInputStream(), destFO.getOutputStream()). Using this code, the operation takes about a minute. I "know" that the FileObjects (sourceFO and destFO) are actual java.io.File objects. When I transform the code to use "direct" file streams for the input and output, the copy operation takes about 12 seconds. it seems like the streams returned by FileObject are causing the slowdown. Since the calls to getInputStream and getOutputStream are used in many places in the product, this may be a bottleneck for performance.
this issue is related to issue 136307.
FilterOutputStream created in FileObject.getOutputStream has to delegate write(byte b[], int off, int len) to underlying FileOutputStream (if case FileObject is backed by File). Otherwise it is copied byte by byte. http://hg.netbeans.org/core-main/rev/a0ed5cb309df
Your test allows for a 10x speed difference... which is pretty close to the level of difference that we were seeing in practice, before the fix. Maybe you should tighten up the test, to fail if the difference between the two strategies is 2x instead of 10x?
Hi Jiri, would it make sense for this change ( http://hg.netbeans.org/main/rev/a0ed5cb309df ) to be incorporated into NB 6.1 patch 2? Vince suggested that the performance improvement to the IDE on windows is noticable.
Integrated into 'main-golden', available in NB_Trunk_Production #236 build Changeset: http://hg.netbeans.org/main/rev/a0ed5cb309df User: Jiri Skrivanek <jskrivanek@netbeans.org> Log: #136308 - fixed performance of FileUtil.copy. FilterOutputStream created in FileObject.getOutputStream has to delegate to underlying stream.
I took a second look at my test methodology and it had some weaknesses... So I did the following test that I think is "stronger". I did an ide build (with the new code). I restarted my windows box. I opened a clock... to see the second hand.. I opened the TM to make sure the system was "done" with its start up busy-work. I started the IDE and watched the second hand. When the clock was covered... I wrote down the time it took to start... 35 second. I then removed the fix. recompiled the ide and did it again... after a full restart. The start-up time for the unpatched code was 45 seconds. So.. the unpatched code took about 28% more time. We should have someone else verify this result.
I was thinking though - this change should have minimal impact on startup because it affects _writing_ of files, not reading. If it really has an impact on startup, that suggests that quite a bit of writing is being done during startup and that just sounds wrong to me. So either the performance improvement for startup is an illusion or some code is not too bright.
> Your test allows for a 10x speed difference... which is pretty close to the level of difference that we were seeing in > practice, before the fix. > Maybe you should tighten up the test, to fail if the difference between the two strategies is 2x instead of 10x? My observations are that a 10x speed difference is enough to catch regressions and also to have the test stable. I have to encounter various configurations on which the test can be run. If you saw 2x difference in your code, please write a new test in your module. Or attach a suggestion how to change my test case. > Hi Jiri, would it make sense for this change to be incorporated into NB 6.1 patch 2? I think it is a safe fix and it can go to the patch. It is up to QE to nominate it.
QE has no objection to add it to patch2 for NB61
Vince, could you verify this issue? It is requirement for integration to patch. Thank you.
verified.
I have to agree with PCW's comment about writing and start-up time. It looks like the IDE would have to write 1.5 megs during start-up to account for the time difference that I was seeing. It must have been some other factor that accounts for the 10 seconds....
The fix has been ported into the release61_fixes branch: http://hg.netbeans.org/release61_fixes/73f77c5ea605
The fix has been rolled back from the release61_fixes branch because of problem with its delivery via AUC.
Please provide more details about this... This bug is huge for Windows users.
More details are available in the issue 139051