[Vm-dev] Profiling and delay accuracy
Andreas Raab
andreas.raab at gmx.de
Fri Jun 15 04:21:59 UTC 2007
Hi Folks -
For a long time now I had this feeling that MessageTally reports pretty
bogus results in many situations without being able to precisely track
down why this would be the case. Today I was looking at
primitiveResponse() and, much to my surprise, noticed that the
checkForInterrupts() that used to be there for years is gone (see
Squeak3.6 for example which still has it). The sole reason for this
check was to get both high delay accuracy and good profiling behavior.
Consider this example:
fc := FormCanvas on: Display.
MessageTally spyOn:[
1 to: 100 do:[:i|
fc fillColor: Color white.
fc printString.
].
].
Using 3.6 this will be measured correctly as:
**Tree**
87.5% {243ms} FormCanvas>>fillColor:
|87.5% {243ms} GrafPort>>fillRect:offset:
| 87.5% {243ms} GrafPort>>copyBits
12.5% {35ms} FormCanvas(Object)>>printString
12.5% {35ms} FormCanvas(Object)>>printStringLimitedTo:
whereas the 3.10 reports it as
**Tree**
99.6% {670ms} FormCanvas(Object)>>printString
94.9% {639ms} primitives
4.6% {31ms} FormCanvas(Object)>>printStringLimitedTo:
I think you can see the problem and just imagine what this does to any
cumulative results. I also wonder what that change does to platforms
that don't have high-resolution asynchronous timers. This used to be the
one place where we would catch timer changes at high resolution and
unless the platform forces high resolution timer interrupts
asynchronously (by resetting the interrupt counter) we must be loosing a
lot in terms of delay accuracy. (it just so happens that the Windows VM
*does* do asynchronous timer interrupts so I never noticed this but I'm
very curious about the difference on Linux which typically still has
pretty bad timer granularity).
Any opinions? My feeling is that the timer check should go back in for
all of the above reasons. At the very least a quickCheckForInterrupt()
is required but I actually think putting the full check back in is worth it.
Cheers,
- Andreas
More information about the Vm-dev
mailing list