Bug 189174 - Strong performance regression on org.eclipse.osgi component
Summary: Strong performance regression on org.eclipse.osgi component
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: 3.3 RC3   Edit
Assignee: Thomas Watson CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2007-05-25 12:47 EDT by Frederic Fusier CLA
Modified: 2007-06-06 10:48 EDT (History)
3 users (show)

See Also:
jeffmcaffer: pmc_approved+
pascal: review+
dj.houghton: review+


Attachments
patch (2.68 KB, patch)
2007-05-29 13:17 EDT, Thomas Watson CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Fusier CLA 2007-05-25 12:47:02 EDT
Looking at performance results of org.eclipse.osgi component for build I20070524-0010, one can see that all perf.StatePerformanceTest#testResolution* tests got strong regressions: between -40% and -130%.
Comment 1 Frederic Fusier CLA 2007-05-26 04:50:46 EDT
Regression confirmed with perf results of I20070625-0010 build
Comment 2 Thomas Watson CLA 2007-05-29 13:17:38 EDT
Created attachment 69093 [details]
patch

The fix for bug 188554 caused the slowdown.  This is only an issue if there are large sets of unresolveable bundles.  The performance testcases have lots of these.

The issue is when setting a bundle to unresolved we need to reinitialize the attached fragments to properly flush exports from the fragments.  But the code will do this over and over for unresolvable bundles.

This fix returns quickly if the bundle is unresolved unless in devmode.  When in devmode extra checks need to be done to ensure fragments remain attached to unresolved bundles.
Comment 3 Thomas Watson CLA 2007-05-30 14:06:27 EDT
Fix released for 3.3 RC3
Comment 4 Thomas Watson CLA 2007-06-04 11:35:48 EDT
The latest performance test results for RC3 still show a performance slowdown but it is improved from RC2.  There is a bug in the performance testcases that create large sets of unresolvable bundles (1000s).  In order to fix bug 188199 some extra work is done when a bundle is unresolved.  This is why the resolver performance testcases are slower.

In a typical eclipse environment the set of bundles will be largely resolvable.  The performance testcase has been updated to create large sets of resolvable bundles.  This is a more interesting performance testcase.
Comment 5 Jeff McAffer CLA 2007-06-04 16:52:14 EDT
totally agree.  We should update the test case to be realistic and representative.

Is there a bug for that or should we use this one?
Comment 6 Thomas Watson CLA 2007-06-04 17:30:09 EDT
I did not open a separate bug.  The testcase update has already been released and tagged for the next build.
Comment 7 Jeff McAffer CLA 2007-06-05 22:34:11 EDT
please mark this a verified when we see the next performance test run. 

Also, did you release changes for 3.2? Kim is rerunning the baseline every week so  we should get updated numbers if the old test is changed.
Comment 8 Frederic Fusier CLA 2007-06-06 09:28:04 EDT
(In reply to comment #6)
> I did not open a separate bug.  The testcase update has already been released
> and tagged for the next build.
> 
The results on these tests are now between -100% and -600% on I20070605-0010 build results! You should have had to rename this test after having changed its content to avoid this kind of trouble...
Comment 9 Thomas Watson CLA 2007-06-06 10:48:03 EDT
I released the fix to the performance tests run against 3.2.  We will not get the results against 3.2 until the next scheduled baseline on June 11th.