Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 332039

Summary:

[perfs] Regression on StartupTest.testApplicationStartup

Product:

[Eclipse Project] Equinox

Reporter:

Satyam Kandula <satyam.kandula>

Component:

Framework

Assignee:

Thomas Watson <tjwatson>

Status:

VERIFIED FIXED

QA Contact:

Severity:

major

Priority:

CC:

daniel_megert, frederic_fusier, john.arthorne, Szymon.Brandys, tjwatson

Version:

3.7

Keywords:

performance

Target Milestone:

3.7 M4

Hardware:

OS:

Windows XP

Whiteboard:

Bug Depends on:

Bug Blocks:

313891

Attachments:

Description	Flags
patch	none

Description Satyam Kandula

2010-12-07 11:01:32 EST

There is a performance regression for the test org.eclipse.core.tests.runtime.perf.StartupTest.testApplicationStartup with build I20101205-2000. 60% regression on SLED10 (Java 5), 13% regression on RHEL 5 (Java 6), more than 100% regression on windows (Java 6). 

The results for N20101214-2000 looks ok and hence the problem should have got introduced only on the 5th.

Comment 1 Dani Megert

2010-12-07 11:24:40 EST

Maybe caused by switch to 1.5? Could also be a problem in RT.

Comment 2 Thomas Watson

2010-12-07 11:49:24 EST

bug328926 and bug330602 may be to blame, but I would be surprised if they caused this kind of slowdown.  I will investigate from an org.eclipse.osgi point of view.

Comment 3 Dani Megert

2010-12-07 11:56:56 EST

*** Bug 332050 has been marked as a duplicate of this bug. ***

Comment 4 Szymon Brandys

2010-12-07 12:38:10 EST

I20101130-0900 contains the fix for Bug 311012 i.e. core.resources switch to 1.5. This build shows no regression, which is introduced between I20101130-0900 and I20101205-2000.

Comment 5 Thomas Watson

2010-12-07 15:49:31 EST

I have reproduced the regression and it appears the fix to bug330602 introduced the regression.  Will investigate more.

Comment 6 Thomas Watson

2010-12-07 16:48:25 EST

Created attachment 184757 [details]
patch

This issue is the change to the constructor of ManifestLocalization.  I moved the access of Bundle-Localization header into the constructor of MainfestLocalization.  This inadvertently caused us to have to parse every bundle's manifest when starting from a cached state.  This is because we don't (and shouldn't) cache the Bundle-Localizaton header.  The extra slowdown is the time it takes to do all the extra parsing of the manifests.

Comment 7 Thomas Watson

2010-12-07 17:02:42 EST

Patch released for M4.

Comment 8 Satyam Kandula

2010-12-08 09:31:20 EST

Did the changes go in I20101207-2000 build? In this build, the performance results are much better, but there still seems to be some regression. With I20101207-2000, 14% regression on SLED10 (Java 5), 4% regression on RHEL5 (Java 6), around 30% regression on windows (Java 6). There is no regression with OpenTextEditorStartupTest#testTextEditorStartup(). 

This could be noise and could be validated through the next build.

Comment 9 Thomas Watson

2010-12-08 10:59:53 EST

(In reply to comment #8)
> Did the changes go in I20101207-2000 build? In this build, the performance
> results are much better, but there still seems to be some regression. With
> I20101207-2000, 14% regression on SLED10 (Java 5), 4% regression on RHEL5 (Java
> 6), around 30% regression on windows (Java 6). There is no regression with
> OpenTextEditorStartupTest#testTextEditorStartup(). 
> 
> This could be noise and could be validated through the next build.

Yes, the fix did make it into this build.  Will have to pay attention to the results on subsequent builds to see if this is noise.

Comment 10 Satyam Kandula

2010-12-22 06:04:54 EST

(In reply to comment #9)
> Yes, the fix did make it into this build.  Will have to pay attention to the
> results on subsequent builds to see if this is noise.
Subsequent builds look good!

Comment 11 John Arthorne

2010-12-22 10:19:58 EST

(In reply to comment #10)
> Subsequent builds look good!

Thanks for verifying Satyam.