[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:

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

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.

   - Andreas

More information about the Vm-dev mailing list