Hmm... #busyWait would eat up more CPU cycles to gain accuracy. What about #waitPrecisely? Then you would not reveal that little implementation detail. And clients could make the decision between #wait and #waitPrecisely depending on whether they need accuracy, not whether they have CPU cycles to spare. Or #waitExactly? There must be some good name out there. :-)

Best,
Marcel
Am 01.07.2021 19:18:36 schrieb Thiede, Christoph <christoph.thiede at student.hpi.uni-potsdam.de>:
Hi all,

I just made an interesting observation:

[1000 timesRepeat: [0.001 seconds wait]] timeToRun. "--> 2612"


I think the reason for this might be that Delay >> #schedule uses a critical section that is also accessed by the TimerEventLoop process with the highest priority in the system, so the synchronization overhead would be the bottleneck in this case.

Instead, if you need to produce many short delays anyway (for instance, to simulate a running process, just like me right new), you can use a busy-wait instead:

Duration >> busyWait

| proceedTime |
proceedTime := Time utcMicrosecondClock + self asMicroSeconds.
[Time utcMicrosecondClock >= proceedTime] whileFalse

[http://www.hpi.de/]
[1000 timesRepeat: [0.001 seconds busyWait]] timeToRun "--> 1000"

Much faster.

Could we need this in the Trunk, too?

Best,
Christoph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210701/8b74281c/attachment.html>