wait 0 doesn't

David Vaughan dvk at dvkconsult.com.au
Tue Apr 29 17:11:01 EDT 2003


On Wednesday, Apr 30, 2003, at 02:01 Australia/Sydney, Jim Hurley 
<jhurley at infostations.com> wrote:
> P.S.
>
> There is an interesting difference between the Mac and PC.
>
> On my  Mac, running the handler:
>
> on mouseUP
>   put empty into field 1
>   repeat 20
>     put the milliseconds into startTime
>     repeat 200
>       wait 1 milliseconds
>     end repeat
>     put  the milliseconds - startTime & comma & space after results
>   end repeat
>   put results  into field 1
> end mouseUP
>
> I get the following results:
>
> 411, 379, 293, 371, 376, 370, 359, 297, 367, 371, 370, 809, 368, 302, 
> 365, 357, 291, 371, 374, 373
>
> with a minimum of 291 and a maximum of 809.
>
> On my PC I get:
>
> 328, 329,329, 331, 329, 329, 329, 331, 329, 330, 329, 329, .....
>
> with  a minimum of 329  and a maximum of 331.
>
> It doesn't appear to be a memory allocation problem. I have 54 megs 
> allocated to  RunRev on my Mac.

Not memory, but your OS, what it is doing and how it goes about it. I 
infer from your saying "I have 54 megs allocated..." that you are using 
OS 9. That OS uses co-operative multi-tasking - after yielding in each 
event loop, Rev can continue when the OS or any other task deigns to 
return control. This would account for very high variability. I ran 
your loop on OS X (667MHz TiBook) and obtained figures from 314 to 413, 
averaging 350. It is tighter because of pre-emptive multi-tasking, but 
variable because I happened to have thirteen other user applications 
(and N system tasks) open at the time, not all of them fast asleep. I 
suspect that when you tested on your PC you had fewer interferences. In 
any event, I very much doubt it is a Rev implementation problem.

regards
David
>
> Jim




More information about the Use-livecode mailing list