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.
Summary: | Web project + GlassFish slowness | ||
---|---|---|---|
Product: | javaee | Reporter: | Petr Jiricka <pjiricka> |
Component: | Web Project | Assignee: | David Konecny <dkonecny> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | vkraemer |
Priority: | P3 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: |
Description
Petr Jiricka
2009-09-15 12:03:42 UTC
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) Changeset: http://hg.netbeans.org/main-golden/rev/eb5aa6e67acb User: Vince Kraemer <vkraemer@netbeans.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. *** |