primitiveMillisecondClock usage (lots but why?)

John M McIntosh johnmci at mac.com
Wed Jul 2 23:19:03 UTC 2003


Well let's see in my test image I see 453 calls to Time  
millisecondClockValue per second when the image is IDLE.

That breaks down say for about 10,000 calls to.

4232->'WorldState>>interCyclePause: WorldState>>doOneCycleFor:  
PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess [] in  
BlockContext>>newProcess)'
3146->'Delay class>>timeoutSemaphore:afterMSecs:  
Semaphore>>waitTimeoutMSecs: EventSensor>>ioProcess [] in  
EventSensor>>startUp [] in BlockContext>>newProcess)'
1229->'WorldState>>runLocalStepMethodsIn: WorldState>>runStepMethodsIn:  
PasteUpMorph>>runStepMethods WorldState>>doOneCycleNowFor:  
WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project  
class>>spawnNewProcess [] in BlockContext>>newProcess)'
1229->'WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor:  
PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess [] in  
BlockContext>>newProcess)'
{etc minor stuff}

Now if I change
EventSensor>>nextEventFromQueue
	"Return the next event from the receiver."
	eventQueue isEmpty ifTrue:[inputSemaphore signal].
	EventPollFrequency _ 500.	"since Squeak is taking the event, reset to  
normal delay"
	eventQueue isEmpty
		ifTrue:[^nil]
		ifFalse:[^eventQueue next]

to not do the inputSemaphore signal because the os-x VM signals the  
semaphore when events come in. This slows the rate to 413 calls per  
second.Then I see a pattern like so:

2758->'1639->'Delay class>>timeoutSemaphore:afterMSecs:  
Semaphore>>waitTimeoutMSecs: EventSensor>>ioProcess [] in  
EventSensor>>startUp )
1400->'WorldState>>interCyclePause: WorldState>>doOneCycleFor:  
PasteUpMorph>>doOneCycle )
1379->'WorldState>>runLocalStepMethodsIn: WorldState>>runStepMethodsIn:  
PasteUpMorph>>runStepMethods WorldState>>doOneCycleNowFor:  
WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle )
1379->'WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor:  
PasteUpMorph>>doOneCycle )
{etc minor stuff}

Well with a little fiddling I can see this pattern.

1288->379   (process 1288 is the io process, 379 millisecondClockValue  
calls)
2825->12157  (process 2825 is the UI process, 12,157  
millisecondClockValue calls).

Mmm I'll need to look further, bet each morphic is doing multiple calls  
to achieve a frame rate, thus lots of calls.


On Wednesday, July 2, 2003, at 10:22  AM, Tim Rowledge wrote:

> John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
>
>> Well the issue is the smalltalk code is calling the primitive every  
>> 2-3
>> milliseconds.
>> This is above and beyond the VM calling the millisecond clock for
>> internal VM usage.
> In the idleloop? I guess there is an interesting (and almost certainly
> platform dependent) issue of how long is a good time to sleep each pass
> round the loop. IF one has a completely reliable OS mechanism to wake
> the vm properly when anything suitable (inpupt event, timer, whatever)
> happens then I suppose the sleep time could be a long time. Last time
> I looked I think the idleloop sleep was 1millisecond.
>
>
> tim
> --
> Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> Strange OpCodes: IKI: Ignore Keyboard Input
>
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===



More information about the Squeak-dev mailing list