Community
Participate
Working Groups
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%.
Regression confirmed with perf results of I20070625-0010 build
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.
Fix released for 3.3 RC3
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.
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?
I did not open a separate bug. The testcase update has already been released and tagged for the next build.
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.
(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...
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.