Hi Eric,
Many thanks for your thoughts !
Note that in this case, our measurements were for “warmstart”. Eclipse had been launched and shut down 3 times before measuring in the profiler; I would thus
expect all disk access to be served from a disk cache.
I would also expect that all I/O and classloading time is aggregated into org.eclipse.osgi (and probably org.eclipse.equinox), which together take
4.4 seconds with -vmargs –Xverify:none already used.
The times in org.eclipse.ui and org.eclipse.e4 would be plain compute times in my understanding (together
3.5 seconds).
We had optimized the classloading for our product a couple years ago, by registering an OSGi hook to “preload” large JARs.
This had given us a 20% improvement launching Eclipse 3.x on Java 6.
Unfortunately, with Eclipse 4.x and Java 7 on modern disks, it turned out that our preloading actually slowed down things
L
So this year, we concluded that we don’t really have control over the time needed for loading classes.
It’s the number of classes multiplied by some factor (small for SSDs, larger for network filers or HDDs, very large if virus scanners are involved on a fragmented
disk on Windows).
So looking at the Eclipse performance test startup fingerprint
http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M6-201503200800/performance/linux.gtk.x86_64/Scenario46.html
it would be really cool if the number of classes loaded could be measured along with the total execution time.
Then we’d have actual numbers to prove the assumption that the increase in startup time is only due to a larger number of classes loaded.
And, one could probably also check whether an increase in number of classes loaded was actually expected or probably unexpected.
Does it sound possible and reasonable adding those statistics to the performance tests ?
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: platform-ui-dev-bounces@xxxxxxxxxxx [mailto:platform-ui-dev-bounces@xxxxxxxxxxx]
On Behalf Of Eric Moffatt
Sent: Friday, March 27, 2015 7:26 PM
To: Eclipse Platform UI component developers list.
Subject: Re: [platform-ui-dev] [equinox-dev] Eclipse Startup Performance
Martin, one interesting thing to do is to see how using an SSD changes these times. With a fast SSD the startup time decreases to a few seconds (at least the one time
we tried it). This means that by far the largest component to the startup time is JAR loading (which is why specifying 'noverify' helps a lot). If the startup time with SSD's is say 3 secs then even it we were to double the performance of the code we'd only
get back 1.5 secs.
TL;DR; From what we've seen the problem seems to be I/O, not the performance of the code itself. Though the code could certainly be improved it may not anything but a marginal advantage for non-SSD
users.
Perhaps we should be looking at ways to optimize the I/O or the JAR structure(s) ?
Onwards,
Eric
"Oberhuber,
Martin" ---03/27/2015 02:09:56 PM---Hi Lars, Thanks for your interest !
From:
"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
To:
"Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
Cc:
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:
03/27/2015 02:09 PM
Subject:
Re: [platform-ui-dev] [equinox-dev] Eclipse Startup Performance
Sent by:
platform-ui-dev-bounces@xxxxxxxxxxx
Hi Lars,
Thanks for your interest !
Let me try by example. We focus on org.eclipse.ui differences between Luna SR2 and Mars:
|
|
|
|
|
|
|
|
Luna SR2
|
|
Delta
|
Mars
|
|
Delta
|
|
|
org.eclipse.ui
|
1 611
|
20%
|
1 583
|
18%
|
(29)
|
1 505
|
16%
|
(78)
|
1 706
|
17%
|
201
|
- In Luna SR2, 1505 msec were total taken in those packages.
- In Luna SR2, This is 16% of the entire startup time.
- The Delta compared to the previous milestone (Luna SR1) is 78 msec faster (=1505 – 1583).
- In Mars, 1706 msec were total taken in org.eclipse.ui*
- In Mars, this is 17% of the total startup time.
- The Delta compared to the previous milestone (Luna SR2) is 201 msec slower (=1706 – 1505).
Let me know if there’s any more questions !
HTH,
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: platform-ui-dev-bounces@xxxxxxxxxxx
[mailto:platform-ui-dev-bounces@xxxxxxxxxxx]
On Behalf Of Lars Vogel
Sent: Thursday, March 26, 2015 5:34 PM
To: Eclipse Platform UI component developers list.
Cc: Equinox development mailing list
Subject: Re: [platform-ui-dev] [equinox-dev] Eclipse Startup Performance
HI Martin,
I have the same issue as Tom: I'm not sure how to interpret the PDF you sent. I'm unsure what the various columns mean.
Can you provide a improve version of these measurements which if easier to process?
Best regards, Lars
On Thu, Mar 26, 2015 at 4:46 PM, Oberhuber, Martin <Martin.Oberhuber@xxxxxxxxxxxxx> wrote:
Hi Tom,
Your suspicion is what I also thought – more classes loaded.
I guess my main question at this point is on the Performance measurement infrastructure, which also seems to indicate a 5.8% degradation on startup performance:
http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M6-201503200800/performance/performance.php
I know that Equinox can trace bundle activations, and some independent measurement of mine show these were actually reduced (80 in Kepler, 77 in Luna, 75 in Mars).
Could the framework also trace the names of classes loaded as part of this scenario (both in the baseline, and latest builds) ?
Then by comparison, one could probably identify classes that should not be loaded ?
Other question goes to Platform/UI and e4 – the second largest contributor to startup time – are there any known inefficiencies, any plans to look at performance in M7 ?
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx]
On Behalf Of Thomas Watson
Sent: Thursday, March 26, 2015 3:03 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] Eclipse Startup Performance
Hi Martin,
There are no plans as of now to work on a performance issue at the framework level. I'm not saying I would not work on a performance issue, just that I am unaware of a performance issue in the framework that contributes to the slowdown you have observed. I'm
not sure how to interpret the PDF you sent. I'm unsure what the various columns mean. My guess is that each release we have more bundles with more classes to load which contribute to more time to start.
This is especially true if you are comparing Luna vs Mars and see a slower time to start. The Luna and Mars framework implementations are virtually identical so my initial guess is we are loading more code to start Eclipse.
Tom
From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
To: "equinox-dev@xxxxxxxxxxx"
<equinox-dev@xxxxxxxxxxx>, "platform-ui-dev@xxxxxxxxxxx"
<platform-ui-dev@xxxxxxxxxxx>
Date: 03/26/2015 08:40 AM
Subject: [equinox-dev] Eclipse Startup Performance
Sent by: equinox-dev-bounces@xxxxxxxxxxx
Hello Equinox and Platform/UI committers,
We recently measured startup performance of our IDE based on Eclipse. We measured 4 milestones:
- 20140325 (based on Kepler SR2),
- 20141014 (based on Luna SR1),
- 20150224 (based on Luna SR2)
- 20150224+mars (based on Mars M5a).
Attached are the findings in summary: for each milestone, the left-hand column has CPU time in milliseconds, relative % within the milestone, and the delta compared to the previous milestone.
The sad news are that startup performance got worse on every iteration – from 8 seconds with Kepler SR2, to almost 10 seconds with Mars M5a.
We used JProfiler to measure warmstart performance after a couple of “restarts” into a Workspace that includes a C/C++ project and had an editor open.
Then, in JProfiler we filtered-out any JDK and JFace packages and made their numbers aggregate up to the callers;
Finally, we accumulated numbers by package prefix to see who’s the biggest contributors to startup time.
We didn’t see any truly significant performance hit, but still the gentle decrease in performance does feel like a “death of a 1000 cuts” issue.
Given that M7 is traditionally a “Performance Milestone”, I was wondering what the committers thought:
Are there any known performance issues that were already planned to be addressed ?
Looking at http://download.eclipse.org/eclipse/downloads/drops4/S-4.5M6-201503200800/performance/performance.php
I see a 5.8% performance decrease on the “Core UI Startup” fingerprint.
Can that be seen as representative for the average user’s IDE startup experience ? How would it compare to a Kepler, or Eclipse 3.8.2 baseline ?
I would be interested in hearing any thoughts.
Thanks!
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools,
Wind River
direct +43.662.457915.85 fax +43.662.457915.6[attachment "201502.pdf" deleted by Thomas Watson/Austin/IBM]
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
--
Geschäftsführer
vogella GmbH
Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (032) 221739404, Email:
lars.vogel@xxxxxxxxxxx, Web:
http://www.vogella.com_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev
