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
|