Community
Participate
Working Groups
when we save a manifest or pde artifact, I'm noticing it's taking a long time, we need tests and profile this before 3.5 is out the door Something is causing a longer time than usual.
Anyone inside of big blue still have access to YourKit? A snapshot of what happens during a manifest save would be interesting to see. We're spinning our wheels somewhere.
*** Bug 274845 has been marked as a duplicate of this bug. ***
I see the same thing.
I'm gonna try to profile the issue using JProfiler. Stay tuned
Thanks Benjamin.
Created attachment 134302 [details] CPU usage of methods for JDT UI (YourKit)
Created attachment 134303 [details] Usage hotspots for JDT UI (YourKit)
I took a couple of quick traces using YourKit 7.5.11 and a Sun 1.5 VM making a trivial change to the manifest for JDT UI - I made a one character change to the ID of the bundle (org.eclipse.jdt.ui -> org.eclipse.jdt.ui1).
Michael, thanks for the data, it helped (jProfiler absolutely wanted to deadlock while saving a manifest.....) I found the guilty code but because of a crappy wireless connection in this hotel room, expect a fix tomorrow...
(In reply to comment #9) > Michael, thanks for the data, it helped (jProfiler absolutely wanted to > deadlock while saving a manifest.....) > I found the guilty code but because of a crappy wireless connection in this > hotel room, expect a fix tomorrow... details ;)?
PluginModelManager line 164: stateDelta contains a looooot of bundles... Thus we update classpath of something like every project in the ws instead of just the relevant set...
I've been a bit hasty with my conclusions... Even if we could probably do things better with regard to the updating of the classpaths of plug-in projects associated to bundles stored in stateDelta (see comment 11), the issue may actually come from a perf. regression in JDT/Core, perhaps due to the fix of bug 265103... I need to investigate a bit more; CC'ing Olivier in the meantime, he may have some good ideas :)
Olivier, looks like we may have a performance issue with JDT?
(thx for the CC Chris) I'm now sure this is a performance regression in JDT, and it was not introduced with bug bug 265103, but with bug 198572 (the one that led to the creation of the ManifestAnalyzer class...). If I switch to org.eclipse.jdt.core v_916 (i.e. just before the release of the fix of ManifestAnalyzer), I am able to obtain much more reasonable saving times!
As I said before, we could propably do things better to not reset a "plugin classpath container" of projects already up-to-date. However, for a workspace containing 235 bundles (plug-ins imported as source from my current target platform: Eclipse 3.5 M7 SDK + all the Mylyn plug-ins), "touching" com.ibm.icu plug-in (on which a lot of other bundles directly or indirectly depend) and then saving it takes about 2s (this is quite much, I know and I repeat that we can certainly optimize the PluginModelManager logic!) with v_916, and *4s* with v_917. Reassigning to JDT/Core for further investigation...
I'll have a look.
Created attachment 134722 [details] Proposed fix Could you please check this patch to see if it improves performances with YourKit or you tell me what is your test case to collect the YourKit data?
Targetting 3.5RC1 if we can verify that this improves performance. David, please review the patch. Michael, could you please get new numbers with YourKit using the patch ?
(In reply to comment #18) > Targetting 3.5RC1 if we can verify that this improves performance. > David, please review the patch. > > Michael, could you please get new numbers with YourKit using the patch ? > Certainly.
The patch looks good because the code of analyzeManifestContents() is equivalent to the previous code and looks more efficient.
Released for 3.5RC1. Michael, please provide new profiling datas with this code.
(In reply to comment #19) > Certainly. > The latest method timings for ManifestAnalyzer is: Method list +----------------------------------------------------------------------------------------------------+-------------+------------------+-----------------+--------------------+ | Name | Time (ms) | Avg. Time (ms) | Own Time (ms) | Invocation Count | +----------------------------------------------------------------------------------------------------+-------------+------------------+-----------------+--------------------+ | +---org.eclipse.jdt.internal.compiler.util.ManifestAnalyzer.analyzeManifestContents(InputStream) | 125 0 % | 1 | 15 0 % | 104 | +----------------------------------------------------------------------------------------------------+-------------+------------------+-----------------+--------------------+ Generated by __PRODUCT_NAME__ May 7, 2009 1:03:39 PM compare to: +----------------------------------------------------------------------------------------------------+-----------------+--------------------+ | Name | Time (ms) | Invocation Count | +----------------------------------------------------------------------------------------------------+-----------------+--------------------+ | +---org.eclipse.jdt.internal.compiler.util.ManifestAnalyzer.analyzeManifestContents(InputStream) | 29,500 12 % | 466 | | | | | | | +---java.io.BufferedReader.read() | 18,312 7 % | 15,490,260 | in the attached report
Verified for 3.5RC1 using I20090513-2000
