Re: [equinox-dev] How to measure and improve Eclipse 4.4 Statup Performance ?
I'm unsure why debug/bundleTime is not suitable for you to figure out long
running bundle activators. The monitor/lazy option only prints stack
traces for lazy activated bundles (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=431491). I don't recall what
trace/activation did in the past, but I can imagine it printed stacks for
all bundle activations regardless of lazy activation. Like I said it was
buried in some complicated code that I must admit I did not write or
maintain and as a result was happy to get rid of :)
No this is not in the migration guide. It could go in there, but I never
thought we treated our trace options as API so I had not considered writing
a migration guide for when we change them. I'm pretty sure this is not the
first time a trace option has been removed or changed in eclipse/equinox.
Do we know if there have been migration guide entries for past changes to
trace options?
Tom
From: "Oberhuber, Martin"
To: Equinox development mailing list
Date: 07/16/2014 12:47 PM
Subject: Re: [equinox-dev] How to measure and improve Eclipse 4.4
Statup Performance ?
Sent by:equinox-dev-boun...@eclipse.org
Hi Tom,
Many thanks for your quick response !
On more testing, the incorrect “Application Started:” message looks like an
issue in the Java Runtime : With Java 7u51 it seems that on computer cold
start (right after reboot), the RuntimeMXBean#getUptime() method lies … in
my case, it takes the JRE 5 seconds to boot up, only then it brings up the
splash screen and uptime starts counting. I’ll do slightly more
investigation and might file a bug against Java since as a user, I need
startup performance end-to-end. Anyways I can find a workaround for that.
The lack of the trace/activation option is a real problem IMO. We had used
that lots of times to understand why unexpected bundle activation happened.
But it seems that org.eclipse.osgi/monitor/lazy is a replacement, can you
confirm ? And if yes, is this documented in a migration guide ?
http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/bundles/org.eclipse.osgi/.options?id=848b9004c041433200cc93227ad95dafc1f83a82
On timing, it’s true that we never had nanosec accuracy in the past, but
Jeff McAffer had requested it in Bugzilla’s (that’s where I go the idea
from). Computers have become faster, and in my tracing I see lots of bundle
times just as “0” … assuming LOTS of bundles with “0” millisec each might
easily add up to noticeable delay. But it’s not a big concern of mine, and
looking at StackOverflow it seems that System.nanoTime() has to be consumed
with caution so it might be better to stay away from that.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: equinox-dev-boun...@eclipse.org [
mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson
Sent: Monday, July 14, 2014 8:02 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] How to measure and improve Eclipse 4.4
Statup Performance ?
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.
Re: [equinox-dev] How to measure and improve Eclipse 4.4 Statup Performance ?
Hi Tom, Many thanks for your quick response ! On more testing, the incorrect “Application Started:” message looks like an issue in the Java Runtime : With Java 7u51 it seems that on computer cold start (right after reboot), the RuntimeMXBean#getUptime() method lies … in my case, it takes the JRE 5 seconds to boot up, only then it brings up the splash screen and uptime starts counting. I’ll do slightly more investigation and might file a bug against Java since as a user, I need startup performance end-to-end. Anyways I can find a workaround for that. The lack of the trace/activation option is a real problem IMO. We had used that lots of times to understand why unexpected bundle activation happened. But it seems that org.eclipse.osgi/monitor/lazy is a replacement, can you confirm ? And if yes, is this documented in a migration guide ? http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/bundles/org.eclipse.osgi/.options?id=848b9004c041433200cc93227ad95dafc1f83a82 On timing, it’s true that we never had nanosec accuracy in the past, but Jeff McAffer had requested it in Bugzilla’s (that’s where I go the idea from). Computers have become faster, and in my tracing I see lots of bundle times just as “0” … assuming LOTS of bundles with “0” millisec each might easily add up to noticeable delay. But it’s not a big concern of mine, and looking at StackOverflow it seems that System.nanoTime() has to be consumed with caution so it might be better to stay away from that. Thanks, Martin -- Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River direct +43.662.457915.85 fax +43.662.457915.6 From: equinox-dev-boun...@eclipse.org [mailto:equinox-dev-boun...@eclipse.org] On Behalf Of Thomas Watson Sent: Monday, July 14, 2014 8:02 PM To: Equinox development mailing list Subject: Re: [equinox-dev] How to measure and improve Eclipse 4.4 Statup Performance ? 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 [Inactive hide details for "Oberhuber, Martin" ---07/14/2014 12:26:15 PM---Dear Equinox Committers, As we've been upgrading our]"Oberhuber, Martin" ---07/14/2014 12:26:15 PM---Dear Equinox Committers, As we've been upgrading our eclipse-based product to Luna, I wanted to vali From: "Oberhuber, Martin" mailto:martin.oberhu...@windriver.com>> To: "equinox-dev@eclipse.org<mailto:equinox-dev@eclipse.org>" mailto: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<mailto: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 –
Re: [equinox-dev] How to measure and improve Eclipse 4.4 Statup Performance ?
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" To: "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: 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
