This was originally a part of issue 170291, I am splitting it out to its own issue, as there are many false duplicates
in issue 170291.
Here is the report relevant to Web Project and GlassFish:
Build: NetBeans IDE Dev (Build 200908022240)
VM: Java HotSpot(TM) Client VM, 1.6.0_01-b06, Java(TM) SE Runtime Environment, 1.6.0_01-b06
OS: Windows Vista, 6.0, x86
Maximum slowness yet reported was 23306 ms, average is 10589
And here is the profiler snapshot:
Looking at http://statistics.netbeans.org/exceptions/exception.do?id=242425 the total time is 3619ms out of which
biggest chunks are spent in:
- org.netbeans.modules.glassfish.spi.ServerUtilities.filterByManifest(): 2422 / 0
- org.netbeans.modules.web.project.ui.customizer.WebCompositePanelProvider.createCategory(): 447 / 0
First one spends about 2000ms in native methods read ZIP files and second one in loading properties.
Vince, what is ServerUtilities.filterByManifest doing?
what does filterByManifest do? future-proof the plugin to some degree.
Earlier in the release cycle, the folks that package the the glassfish code would reshuffle the paths and content of the
jars that contained classes that support Java EE 6 development.
This random shuffle would break the Java EE 6/Glassfish development environment badly... usually at a time when we
needed it to be stable...
So, we established a convention that would allow the packagers to have the freedom to mess with names and content of
jars and the plugin to calculate the GlassFish server's library content dynamically.
This has served us well.
At this point, we may be able to revert to a static list of jars, safely... but I would like to avoid it.
I will retest this on some mid size projects just to see what's the penalty.
what if I make the call to initLibraries() async? The IDE will start to build the list of classes/jars when the
Hk2JavaEEPlatformImpl is being built and must finish building the list before a call to
Hk2JavaEEPlatformImpl.getLibraries() can complete... but if the call to getLibraries() happens much later (about 3
seconds later in this case), the call will be able to return 'immediately' with the correct data.
I'm not familiar with your code but if you are saying that you can return immediately and perform time consuming
operation later in a background thread then yeah go for it.
Integrated into 'main-golden', will be available in build *200909181401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Vince Kraemer <firstname.lastname@example.org>
Log: #172274: push filterByManifest onto separate thread.
Fixed by Vince. And if not we will get a new different perf report.
*** Issue 173978 has been marked as a duplicate of this issue. ***