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.
Created attachment 99429 [details] snapshot Have a look at the snapshot. Product Version: NetBeans IDE Dev (Build 100521-ea4985d4f1ae) Java: 1.6.0_20; Java HotSpot(TM) 64-Bit Server VM 16.3-b01 System: Linux version 2.6.32-22-generic running on amd64; UTF-8; cs_CZ (nb)
I'll see what I can do with this when fixing bug 184854.
*** Bug 186791 has been marked as a duplicate of this bug. ***
Another 60s NPS: http://netbeans.org/bugzilla/attachment.cgi?id=99531
Created attachment 99598 [details] one more snapshot
Created attachment 99754 [details] one more snapshot
Start traversing FS using FileObject map 1 ls time: 15443ms; 183612 wrappers where 38118 for dirs Start checking time stamps using FileObjects map 1 time 1: 3487 time 2: 3366 time 3: 3486 time 4: 3508 time 5: 3422 ------------- FS.refresh statistics (183,401FileObjects): FileSystem refresh: 1 calls in 353091ms Invocation of FileChangeListeners: 0 calls in 0ms Folder refresh: 0 calls in 0ms File refresh: 328680 calls in 342364ms FS.refresh statistics (38,125FileObjects): FileSystem refresh: 1 calls in 33565ms Invocation of FileChangeListeners: 0 calls in 0ms Folder refresh: 0 calls in 0ms File refresh: 243276 calls in 24808ms
Created attachment 99791 [details] application demonstrating issue of slowness
353091ms is a good candidate to be fixed asap
Created attachment 99811 [details] Speed up I can speed the implementation a bit and make it O(n) instead of O(n^2). However the problem is not fixed, I am afraid. The time needed to find even small number of children is still quite high, as it depends on the number of FileObject in memory. Rather the implementation shall change and time time shall be proportional to number of existing children. The numbers below show that it does not matter how many children we have, the time is always the same, guided by those 170000 of existing files. [NamingFactory]: 318 children for /nb/main/wlm.editor/src/org took 36 all names: 176746 [NamingFactory]: 17 children for /nb/main/cnd.navigation/test/unit took 39 all names: 176713 [NamingFactory]: 21 children for /nb/main/j2ee.ant/build took 45 all names: 176704 [NamingFactory]: 6 children for /nb/main/j2ee.ant/src took 40 all names: 176683 [NamingFactory]: 12 children for /nb/main/j2ee.ant/antsrc took 69 all names: 176677 [NamingFactory]: 2 children for /nb/main/j2ee.ant/nbproject took 53 all names: 176665
*** Bug 186482 has been marked as a duplicate of this bug. ***
*** Bug 186897 has been marked as a duplicate of this bug. ***
*** Bug 186890 has been marked as a duplicate of this bug. ***
*** Bug 187358 has been marked as a duplicate of this bug. ***
*** Bug 187403 has been marked as a duplicate of this bug. ***
I believe this is fixed by #8 build of http://deadlock.netbeans.org/hudson/job/prototypes-immutable-file-name-184854/ at least when running Vladimir's test application, the CPU is not occupied any more, and most of the time is spend by I/O operations.
My tests seem to indicate that my fix for bug 184854 also reduces the CPU usage in collectChildren method (by deleting it). Marking as duplicate, please verify. *** This bug has been marked as a duplicate of bug 184854 ***
Integrated into 'main-golden', will be available in build *201006150001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/3c7f40a1c126 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #186655: Effectively eliminating slowness of collectChildren method by deleting it.
Jarda, you have closed bug as duplicate, but commit message was put here. Please, resolve which one to integrate into 6.9.1 Thanks, Vladimir.
As soon as stabilized, all commits from branch immutable-file-name-184854 will be the ones to backport.
I can confirm that this issue seems to be fixed.
great! now current numbers are the same for both runs (the first and following) and it is the same as was before for the second run. Speed is still now good (original P3?) -------------- Start traversing FS using FileObject map 1 ls time: 17704ms; 183612 wrappers where 38118 for dirs Start checking time stamps using FileObjects map 1 time 1: 4834 time 2: 3432 time 3: 3467 time 4: 3524 time 5: 3435 attach recursive listener to FileObject...10101 Done traversing FS using FileObject map 1 ------------------------------------- FS.refresh statistics (183,614FileObjects): FileSystem refresh: 1 calls in 28188ms Invocation of FileChangeListeners: 0 calls in 0ms Folder refresh: 0 calls in 0ms File refresh: 329107 calls in 30541ms FS.refresh statistics (183,614FileObjects): FileSystem refresh: 1 calls in 25906ms Invocation of FileChangeListeners: 0 calls in 0ms Folder refresh: 0 calls in 0ms File refresh: 329107 calls in 29266ms
(In reply to comment #21) > great! now current numbers are the same for both runs (the first and following) > and it is the same as was before for the second run. Speed is still now good > (original P3?) I meant that imho speed is *not* good (original P3?), because it's 6 times slower than could be :-)
*** Bug 188856 has been marked as a duplicate of this bug. ***
*** Bug 189006 has been marked as a duplicate of this bug. ***