I would be good to get a bug open to discuss your requirements or observed
bugs to find a fix.
You are correct that we removed some internals from equinox in luna that
were adding to the overall size and complication of the framework. Much,
if not all of the removed functionality could be implemented on top of the
framework using either standard OSGi APIs or a framework extension. But we
did not put additional work into the runtime spy to migrate to use
something else other than the removed internals. I suggest a separate bug
against Eclipse->Runtime for that since that bundle has never been part of
Equinox. Or actually built by the eclipse/equinox builds.
I'm not sure what you are describing for the Application Started: message.
The messages for that seem to be identical to the way they were in kepler
and also seem to be accurately displayed once the splash screen is brought
down. If you are saying the time between when the splash screen is taken
down until when you see the UI is taking 5 seconds then we have a real UI
issue here and that should be brought up with the Eclipse-UI folks (but
that is not my observation locally).
The trace/activation option is no longer supported in the framework itself.
That would need to be done on top of the framework.
If you think debug/bundleTime should use nano-seconds then a separate bug
is appropriate. Although I would be surprised if the previous timings
recorded in Kepler used nano-seconds, so I am not sure why this timing is
useless compared to the timings you could gather before.
Overall: I am not keen on adding any of this back by default directly in
the framework implementation. It all should be done on top in order to
keep the internals of the framework more simple.
Tom
From: "Oberhuber, Martin" <martin.oberhu...@windriver.com>
To: "equinox-dev@eclipse.org" <equinox-dev@eclipse.org>
Date: 07/14/2014 12:26 PM
Subject: [equinox-dev] How to measure and improve Eclipse 4.4 Statup
Performance ?
Sent by: equinox-dev-boun...@eclipse.org
Dear Equinox Committers,
As we’ve been upgrading our eclipse-based product to Luna, I wanted to
validate that our startup performance is still good:
· get an *exact* measurement for the wallclosck time Eclipse
takes from double clicking eclipse.exe to seeing the UI,
· get activation traces, such that I can debug reasons for
bundle activations that are unexpected,
· get some per-bundle timing information to understand which
bundles contribute most to startup time.
In the past, all that was possible using –debug org.eclipse.osgi tracing
options, plus Core Tools runtime spy. But it looks like ALL of the
infrastructure is now broken in Luna:
1. BundleStats are no longer collected for usage in Runtime Spy
– looks like this feature was just removed:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=412502
As a result, the Runtime Spy looks pretty much useless – there’s no
data in the “Runtime Spy” perspective at all even though monitoring
is enabled.
2. The org.eclipse.osgi/trace/activation=true tracing option
doesn’t print activation stack traces to “runtime.traces” any more
(is this just a bug / oversight or am I doing something wrong?)
3. The Application Started: <timestamp> output which we get
with –debug –consoleLog does not seem to be accurate any more.
Measuring wallclock time, Eclipse is on average 5 seconds slower than
indicated by the timestamp.
Reading the docs, I found a reference to the newly introduced
debug/bundleTime tracing option, but I’m unsure how to interpret the data;
it also seems to be very inexact and thus useless to me (getting nanosecond
resolution would be good
when available).
Is there any new infrastructure available to get me the data I need ?
How do others measure and improve startup performance ?
Shall I just file defects for the regressions observed ?
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/equinox-dev
