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