[Vm-dev] Profiling and delay accuracy (was: Profile interpretation)
David T. Lewis
lewis at mail.msen.com
Sun Jul 24 16:01:50 UTC 2011
Moving discussion to vm-dev for follow up
On Sun, Jul 24, 2011 at 01:25:37PM +0200, Andreas Raab wrote:
> On 7/24/2011 10:11, Hilaire Fernandes wrote:
> >Looking at the profile, I see in the iPad a lot of time spent in the
> >method #idleProcess. The #eventLoop also counts for a lot.
> >I don't know how to interpret these two results.
> If time is spent in the idleProcess it is usually a good sign. Time
> assigned to the idleProcess is time in which your system didn't do a
> thing, so you have resources to spare. Usually this means you were
> running a UI interaction in which case there is always some idle time
> inbetween the Morphic interaction loop.
> The bad news about the profile is the time spent in the eventLoop. The
> reason it's bad is that this is a clear sign that the profiler is bogus.
> I have commented on that many times in the past; basically the profile
> you have is almost entirely useless (see  for a good example of how
> bogus the results are).
> Your best bet at this point is probably to go back to a VM that doesn't
> have the problem (probably as far as 3.6 if that's feasible) or to
> extract the OpenQwaq system profiler which you could then run on the
> desktop (I'm not sure if it's supported by the Stack VM; you could try
> it to see if it works on the iPad as well).
>  http://lists.squeakfoundation.org/pipermail/vm-dev/2007-June/001410.html
This discussion seems to have died out prematurely without conclusion.
I opened Mantis 7653 to document the issue:
My impression from reading the earlier discussion is that MessageTally
accuracy was sacrificed in an attempt to gain performance, and that
the right thing to do is to add the interrupt checks as suggested
by Andreas, measure the actual impact on performance, and leave the
interrupt checks in place if performance does not measurably suffer.
I cannot follow up further right now, but hopefully the Mantis
report will keep the issue from being lost (again).
More information about the Vm-dev