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.
Startup time of NB4.1 builds is 5-10% longer than for NB4.0. The biggest contributors to this according to comparision of NB41EA1 and NB40builds on my Dell 840Latitude notebook are: - growing number of modules. Processing of module sections is about 150ms slower (200 -> 350). - ModuleInstalls processing has 800ms regression mainly comming from com.sun.tools.appserver/1 360ms=, org.netbeans.modules.websvc.registry 35ms, org.netbeans.modules.project.libraries/0 280ms (350 -> 630).
com.sun.tools.appserver/1 startup should be much faster noow. Can you uppdat the bug with new numbers... Also, we need to know when the bug can be closed, i.e what is the target per module.
Target is no regression, as always. ;-) A few millis are acceptable I guess.
this target is not acceptable. J2EE area is adding between 15 to 20 new modules. If this target was acceptable, then NetBeans would start in ZERO seconds, since the n modules that compose NB4.0 would start in no time. :-) Please clarify or I will close the bug as not a bug.
I see your point. But we want to keep continually startup time in a reasonable boundaries. Adding more modules does not necessarily have to mean significant startup time increase. Officially the approved PBS target for startup is "no regression" with the boundary of "15% regression". We have to do as much as possible to keep as close to promo-D as possible. And we may, of course, in the end improve startup time in some other area, but we cannot rely on this compensation. So, please, do your best in your area.
We will verify the improvement you mentioned above and attach new numbers to this issue.
I am checking with the trunk build from Nov 12. project.libraries startup now takes even longer time 1000-1200 ms. This needs to be investigated com.sun.tools.appserver and org.netbeans.modules.websvc.registry ModuleInstalls now take only milliseconds
while looking at profiler output we see that creating of FolderInstance and of associated lookup called by LibraryTypeRegistry.getLibraryTypeProvider spents a lot of time in XML parsing now. This can be caused by newly introduced MIME resolvers. Tomas is going to verify if this is the reason / how much this contributes to the regression.
I've did some measurements and found that the LibraryTypeprovider.provider.libraryCreated () takes a long time when called first time. Doing Lookup:33 ms Storage Init: 1 ms intron: 12ms readLibrary: 40ms ------->Provider.libraryCreated: 239ms readLibrary: 4ms Provider.libraryCreated: 9ms readLibrary: 2ms Provider.libraryCreated: 5ms readLibrary: 3ms Provider.libraryCreated: 7ms readLibrary: 3ms Provider.libraryCreated: 5ms readLibrary: 4ms Provider.libraryCreated: 3ms all libraries: 330ms Storage Load: 342 ms Libraries Module Init:343 ms There are two possible solutions, reschedule the libraries init into other low prioriry thread. Remember time stamps of library definition files and call libraryCreated() only for definitions which changed. This will not help to the first start of IDE, but other starts should be faster.
Created attachment 19741 [details] Patch for measuring times.
Created attachment 19744 [details] Patch for calculating time stamps.
I've created a patch for timestamping library definitions. Now it seems that most of time is spent in the parsing of the first library, it also depends on modules order. It seems that the parsing of first library loads the XML parser classes.
The libraryCreated is called only for libraries which are new or modified, this helps on non first start. Checking in LibrariesStorage.java; /cvs/projects/libraries/src/org/netbeans/modules/project/libraries/LibrariesStorage.java,v <-- LibrariesStorage.java new revision: 1.16; previous revision: 1.15 done
Now the biggest time is spent in reading the first library if no other module has already leaded the xml parser (this depends on the order of module loading)
Radime, please, could you verify this issue, Thanks.