Bug 258259 - [perfs] State Resolution test is slower than 3.4
Summary: [perfs] State Resolution test is slower than 3.4
Status: VERIFIED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: 3.5   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.5 M7   Edit
Assignee: Thomas Watson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 270824
  Show dependency tree
 
Reported: 2008-12-10 05:49 EST by Frederic Fusier CLA
Modified: 2009-05-06 05:37 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Frederic Fusier CLA 2008-12-10 05:49:44 EST
Looking at I20081209-0100 performance results, it looks like the scenario:
org.eclipse.osgi.tests.perf.StatePerformanceTest#testResolution1000()
got a regression since 3.4.

The numbers for this test are really stable for all test machines:
Win XP Sun 1.5.0_10 (2 x 3.00GHz - 3GB RAM)
Builds          State Resolution
I20081118-1720	-28.0%
I20081119-1600	-27.0%
N20081120-2000	-27.0%
I20081125-0840	-28.0%
N20081127-2000	-29.0%
N20081129-2000	-29.0%
I20081202-1812	-29.0%
N20081204-2000	-30.0%
I20081209-0100	-27.0%

SLED 10 Sun 1.5.0_10 (2 x 3.00GHz - 3GB RAM)            
Builds          State Resolution
N20081117-2000	-267.0%
I20081118-1720	-30.0%
I20081119-1600	-30.0%
N20081120-2000	-30.0%
I20081125-0840	-29.0%
N20081127-2000	-30.0%
N20081129-2000	-30.0%
I20081202-1812	-31.0%
N20081204-2000	-29.0%
N20081206-2000	-31.0%
I20081208-0921	-33.0%
I20081209-0100	-32.0%

RHEL 5.0 Sun 6.0_04 (2 x 3.00GHz - 3GB RAM)
Builds          State Resolution
N20081117-2000	-24.0%
I20081118-1720	-24.0%
I20081119-1600	-25.0%
N20081120-2000	-25.0%
I20081125-0840	-23.0%
N20081127-2000	-23.0%
N20081129-2000	-23.0%
I20081202-1812	-24.0%
N20081204-2000	-21.0%
N20081206-2000	-24.0%
I20081208-0921	-24.0%
I20081209-0100	-23.0%
Comment 1 Thomas Watson CLA 2008-12-11 14:24:13 EST
The slowdown started when the fix for bug 247522 was released for the I20081118 build.  This is expected since we have added synchronization to the resolver data structures in order to make them thread-safe.  We had serious thread-safety issues that needed to be addressed.  We cannot remove the synchronization to gain back the time lost due to synchronization.  We would have to look at other options to speed up the resolver if we really need to gain the time lost back.

Resolution results are cached so any performance loss here is not going to be measurable from an cached start.
Comment 2 Frederic Fusier CLA 2009-03-17 13:14:01 EDT
So, could you add a comment this test to make it gray in the fingerprint?
Then, you could close this bug as fixed :-)
Thanks
Comment 3 Frederic Fusier CLA 2009-04-29 04:40:57 EDT
Thomas, would it be possible to set the comment on the test to have it grayed in the fingerprint before M7?
TIA
Comment 4 Thomas Watson CLA 2009-04-29 10:33:42 EDT
Done in for M7.
Comment 5 Frederic Fusier CLA 2009-05-06 05:37:39 EDT
Verified for M7 with I20090430-2300 results