I'd suggest timing a loop that does an assignment (a <- b) across a few  
million iterations keeping any counter < SmallInteger maxVal
to prevent usage of large positive integers.

Then time same loop with a call to get the millisecond clock.
Some math will tell you how expensive this is.
Keep in mind the overhead for  the VM to call the clock is *much* lower.

Smalltalk Process Context switches occur at least 60 times per second.  
Really it's tied to the morphic frame rate plus other things going on.
Even if you say 100 times a second, then what is the performance cost  
in seconds per 24 hours?


On Oct 9, 2004, at 2:51 AM, Stephan Rudlof wrote:

> John M McIntosh wrote:
>> I'm not sure I understand your question. The change created three
>> instance variables, one being the time a switch started,
>> another the time it ended, the last the total incremental  
>> milliseconds.
>> At process switch time I'd read the millisecond clock
>> and do a subtraction, a validity check, then add to the total.
>
> I don't see a problem in the instance variable changes in Process.
>
> I would like to know, if the overhead for these measurements is so low,
> that there is no problem to use these modified VM and image *regularly*
> (e.g. in V4). Another variant would be to compile a special VM and to
> generate a special image for these measurements (with or without V4).  
> In
> between would be a VM flag controlling if the time should be updated or
> not, which could be set by a prim.

>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===