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.
Using -J-Dorg.netbeans.log.startup=print on the dev build from 11/12/2002 I discovered that the module system spends 50% more time in processing module sections than in dev build from 10/01/2002 Nearly every module with some manifest sections now takes longer to process but it seems that loader sections are more (or only) affected. The worst case is web.core module (containing a lot of loaders) which changed from 172ms to 352ms on my machine. As I've not found any direct change in that part of module system/LoaderPoolNode, I think the problem may lie elsewhere (DataLoader impl?) Reassing if you think you couldn't cause it in that time frame.
I've narrowed the time frame for this regression to 20021101-20021104 The only difference I found in the module system are autodependencies on comp/exec/io which doesn't caused it (I've tried to run with -J-Dorg.netbeans.core.modules.NbInstaller.NO_COMPAT_AUTO_DEPS_COMP_EXEC_IO=true and the regression was still there. I suspect the regression comes from class loading but I've not proven it.
Have you ruled out simple overhead from the web module depending on the new API modules? Is other class loading affected, or just manifest section processing, or don't you know? I didn't touch anything specifically related to creating loaders.
My suspicion: rather than any core change per se, the extra time is spent warming up class loading from three new parent modules (in the case of web/core and many other modules). Perhaps this takes longer for some reason. Since org/openide/ and org/netbeans/core/ are not in the domain cache according to NbInstaller (this was true since Oct 16), when doing class loading for org.openide.** classes, all parent class loaders must be searched. The number of parent loaders increased by three. However it was already a lot, and searching through class loaders is not the major component in loading classes, so that would not explain a 50% increase in time to load loader classes. I tried a CVS diff between these builds but did not see anything obvious.
Afraid to say I can't find anything useful. OptimizeIt! run on a current dev build confirms that around 3.3% of startup CPU time is spent loading loader sections, most of that taken up by class loading. I don't see anything especially wrong with that class loading. My current hypothesis: execution & compiler API classes are still being loaded during startup. However whereas before they were loaded early by the core infrastructure - e.g. because TopManager referred to them - now they are loaded later by module sections. So the work is shifted forward in the startup sequence, without absolutely increasing. Just a guess though.
Startup time got a little slower (not surprising given that several modules were added): Average times: BLD200211010100 14.2476286172867 std. dev. 0.491818115272231 BLD200211040100 14.7037110010783 std. dev. 0.421656675855274 Improvement: -0.456082383791605 Percentage: -3.20111083775892%
Nope, examination of times + verbosegc shows that the classes loaded during each loader section is almost the same between the two builds; the class loading just got slower.
ProxyClassLoader.getPackage seems to recurse too much. That is one problem. It should jump straight to the right parent, just like loadClass. Adding the new API modules probably increased the depth of the module dependency tree, which could bring out this effect.
Created attachment 8359 [details] Useless patch - saves maybe .3% (1/6 of std dev)
#29834's patch (dealing with gratuitous recursion in PCL.getPackage) seems to restore about 12% of the manifest section time in NB. That probably accounts for some of the slowdown. For the rest, I just don't know for sure, but would guess that the additional parent classloaders contribute. I rechecked profiler results for the manifest section loading period and don't see anything unreasonable.
verifying.