[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[equinox-dev] Huge performance loss between Kepler and Luna/Mars on first start
- From: Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
- Date: Fri, 20 Feb 2015 18:36:10 +0100
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
I've been with a customer today who wants to update from Eclipse 3.x
Kepler to the 4.x code base and so he naturally inherits the latest
Equinox implementation who has changed in between those releases.
The intial boot time increased from about 2 seconds to ~20 seconds on
Mars (on Luna Equinox or better said Felix-Resolver crashes).
We profiled the bootstrap process and the whole time (95%) is eaten up
the by felix resolver ResolverImpl#mergeCandidatePackages
Looking at tbe hot methods we see:
* 15% of the time is spend in ArrayList.contains()
* 30% of the time in HashMap.getNode()
- called from ResolverImpl#mergeCanidatePackages 7%
- called from ResolverImpl#calculateExportedPackages 5%
- called from ResolverImpl#mergeUses 5%
Looking Allocation counts we see the biggest amount (1.9GB) being caused
by ArrayList.grow where we could track back 1.84GB to
mergeCandidatePackages once more which suggests that the initial sizes
choosen for the arrays there are probably not optimal.
One very interesting to this piece of software is that it uses:
a) only require bundle - not very unnatural for Eclipse apps
b) a loooot of reexports!
Would it be possible to:
a) replace the lists through sets? This should improve the contains check
b) use better initial array sizes?
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck