[BUG] why is frame rate in 3.2.5 slower?

John M McIntosh johnmci at smalltalkconsulting.com
Thu Mar 14 19:31:14 UTC 2002


>John M McIntosh <johnmci at smalltalkconsulting.com> wrote:>
>  > I changed my ioRelinquishProcessorForMicroseconds to do
>>	GiveUPControlToCPU();
>>           if (nextWakeupTick != 0 && ioMSecs() >= nextWakeupTick)
>>               interruptCheckCounter = 0;
>>
>>
>
>Oh good grief.  Let me get this straight.  Squeak asks to suspend itself
>for 10 milliseconds (or whatever), and then when it comes back, it
>doesn't check for delays that have come to pass in that time?  Is that
>right?

The number coming down from the VM is 1000 microseconds (1 ms).
Yes, you've given up control for at least that amount of time, then 
no check for expired timers. Returning earlier is a function of how 
you do the sleep tho.

In this test example, we ask for a 1ms delay, which results in an 
ioRelinquishProcessorForMicroseconds which then won't be done 
correctly because you do a couple of 
ioRelinquishProcessorForMicroseconds until you realize a delay hasn't 
expired.


>
>If that's true, then yes, change it!  Whenever Squeak comes back from
>sleeping, check the IO and check to see if a Delay needs to be woken up.
>
>This shouldn't be a time drain.  After all, the VM has just gone to
>sleep -- there can't be anything so pressing that a couple of system
>calls will be a problem.  Also, don't check the time -- on Unix, and
>probably other platforms, if ioRelinquish returns early it's because
>there really is something that has happened -- thus the sooner you get
>back, the *more* likely you should check for events.

We need to check for the expired timer because of how 
checkForInterupts works. But keep reading.


>
>
>By the way, if you have access to high-precision timers, then maybe you
>should fire up a timer right before going to sleep, and have it fire
>just once to wake you back up?  Then you'll know exactly what to set the
>timer for.

Mmm in the left hand you have a delay timer pop upcoming, in the 
right a duration, you need a clock call anyways to make the 
calculation
wakeuptime-msecs()
Baring clock rollover logic.

Now I'm wondering here if you could really just halt Squeak until either
a) the next delay time ends
b) UI interactions occurs.

I guess I could try it, so do I have any linux/bsd folks who would 
like to experiment by building a new VM?

>
>
>
>>  >Somehow I thought the os-x scheduler snatchs control away for 1/60
>>  >of a second, but that doesn't jive
>>
>>  Ah, thats because there is a lower limit for the
>>  interruptCheckCounter counter (1000). So it just happens running 1000
>>  *interesting* bytecodes interspersed with usleep() takes 16ms or so.
>
>It's a big coincidence, though.  And on Linux, it seems to take 10 ms.
>Do you know how to adjust this parameter?  It would be neat to see what
>happens if you half it or double it.

It's value used to check interruptCheckCounterFeedBackReset and the 
assignment in checkForInterrupts.

>
>
>
>-Lex
>
>
>
>PS -- a little detail that has bugged me for a while, is that the idle
>process doesn't check what Delay is doing.  It would be nice if it
>modified the amount of time to sleep depending on the time before the
>next delay will trigger, instead of just saying "1 millisecond" all the
>time.  Alternatively, the ioRelinquish primitive could check this --
>doesn't the VM know when the next Delay is supposed to fire?

Ah, see above.
-- 
--
===========================================================================
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