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.
Loaders found in module's manifests are added separatelly and each such addition causes fires resort() which is O(N^2), so that the addition of M loaders is about O(M^3). During the startup, the module system should gather all the loaders and add them all at once to the loader pool, reducing the complexity to O(M^2).
Created attachment 5168 [details] 200 simple testing modules, each adding one loader.
I tested to run the IDE with the testing modules only and it took about 70s to startup. When I commented out the call to resort() in LoaderPolNode.java, it started in ~17s Standard NB is sped up by about 400ms by not calling resort() during adding the modules, so calling it only once during the startup would give us about 300-350ms.
E.g. in FFJ EE is startup about 1s faster without calling resort().
Thanks for finding this - shouldn't be too hard to fix, I think.
Actually, Andrew found it. Do you think the patch will be simple enough to go to 3.3.2? I don't myself think this should go in, but J.Grodnik has asked.
Created attachment 5256 [details] Binary patch JAR for r33; place in lib/patches/ and restart
Created attachment 5257 [details] Source patch for release33 sources
Fixed in the trunk: committed * Up-To-Date 1.58 core/src/org/netbeans/core/LoaderPoolNode.java committed * Up-To-Date 1.30 core/src/org/netbeans/core/modules/NbInstaller.java
I have made a source patch (should work against release33 sources) and a binary patch (from the source patch, should work in release33-based builds). It does indeed seem to help startup time in EE. Testing methodology: - using FFJ EE Orion EA (from CD installer) - machine: PIII/500 256Mb Linux 2.2.12; JDK 1.3.1_02; light load - other running apps: X (Gnome, Enlightenment) + FSF Emacs - script-based test sequence from shell: -- begin with fresh user dir -- 4 primer runs (each once with binary patch, then once without patch) to ensure disk files are swapped in and to stabilize the system -- 10 measured runs (again, alternating patch then no patch) - using -J-Dnetbeans.close=true and measuring elapsed time - mean with patch: 35.3 sec (standard deviation 0.26 sec on 10 samples) - without: 34.3 sec (s.d. 0.23 sec) - difference: .994 sec or about 2.8% The performance improvement I saw was four standard deviations, which is significant. My personal recommendation is to try to get this in 3.3.2 on the grounds that (1) a one-second startup time improvement is quite a lot as these things go, (2) the patch is rather simple. I would appreciate a code review (Petr or anyone else in core team) and a QA sanity-check.
The patch is OK as far as I understand the module system. To your results: I guess you've interchanged with/without results, otherwise I'll be strongly against the patch :-)
Yes, I'm sorry - each run was w/o patch first then w/ patch. I got it backwards.
Now in orion_fcs too: Checking in src/org/netbeans/core/LoaderPoolNode.java; /cvs/core/src/org/netbeans/core/LoaderPoolNode.java,v <-- LoaderPoolNode.java new revision: 1.51.14.3.4.2; previous revision: 1.51.14.3.4.1 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/core/modules/NbInstaller.java; /cvs/core/src/org/netbeans/core/modules/NbInstaller.java,v <-- NbInstaller.java new revision: 1.20.14.1.4.1; previous revision: 1.20.14.1 done
verified for trunk and 020408_1
Resolved for 3.4.x or earlier, no new info since then -> closing.