Hi Marcel,

to me as a non-domain expert for this stuff, both #waitExactly and #waitPrecisely would just sound "better" than normal #wait (similar to names such as "PluggableTextMorph*Plus*" or "JPEGReadWriter2"). #busyWait, on the other hand, is something I would have considered a pretty popular term - it alerts me directly that this will be a busy and resource-intensive operation. But maybe that's just my impression. :-)

Best,
Christoph

> 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>
> 
>