Performance profiling results...

Tim Rowledge tim at sumeru.stanford.edu
Tue Sep 25 16:13:49 UTC 2001


Scott A Crosby wrote:

> I don't want a time, just a cheap stopwatch that I can check to see if
> something took too long. No long-term stable timer.
> 
Scott, remember platform issues are important here. The code you are
looking at is generated from slang (mostly) and so has to work on all
platforms including those without an OS. That applies to places where
you are wanting to optimise for cache line sizes and aranagements; the
cache on an ARM is very different to that on an x86 or PPC. None of this
prevents you from making improvements, but simply means you have to
think much more broadly. Sections where you absolutely have to do
platform specific things are easy enough to split out, but often it
takes many iterations to find a configuration that can work for all systems.

For timing of potentially long running primitives I have a suggestion
that might be useful. Since the timer checking seems to be pretty
expensive to use for checking every primitive, why do it for every
primitive? VisualWorks uses (well used to, when I was managing the
group) a technique of letting the write of the primitive specify if it
is a likely long running prim. We could do something similar in Squeak
quite easily; drop the timer checking by default and come up with some
way to say when the prim needs the checking.
Two ideas come to mind right now:-
1) add a pragma (like 'self inline: boolean' in translated methods) that
tells the codegen to wrap a timer around the prim code
2) an explicit claim by the prim that it knows it will be a long runner
(many IO prims would count)
3) must be others.

The cost of these mods is pretty small, mainly a simple tedious edit of
many prim methods.

tim




More information about the Squeak-dev mailing list