<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
                                        > [...] <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">both #waitExactly and #waitPrecisely would just sound "better" than normal #wait [...]</span><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Ah, that's right. We wouldn't want to make everybody start using #waitExactly. Then it's maybe better to encode the "trade-off" directly in the message name. The method's comment should then reveal why it is there and that the normal use should be #wait. :-)</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px"><br></span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Best,</span></div><div><span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Marcel</span></div><div class="mb_sig"></div>
                                        <blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
                        <p style="color: #AAAAAA; margin-top: 10px;">Am 02.07.2021 15:58:17 schrieb christoph.thiede@student.hpi.uni-potsdam.de <christoph.thiede@student.hpi.uni-potsdam.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Marcel,
<br>
<br>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. :-)
<br>
<br>Best,
<br>Christoph
<br>
<br>> 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. :-)
<br>> 
<br>> Best,
<br>> Marcel
<br>> Am 01.07.2021 19:18:36 schrieb Thiede, Christoph <christoph.thiede at="" student.hpi.uni-potsdam.de="">:
<br>> Hi all,
<br>> 
<br>> I just made an interesting observation:
<br>> 
<br>> [1000 timesRepeat: [0.001 seconds wait]] timeToRun. "--> 2612"
<br>> 
<br>> 
<br>> 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.
<br>> 
<br>> 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:
<br>> 
<br>> Duration >> busyWait
<br>> 
<br>> | proceedTime |
<br>> proceedTime := Time utcMicrosecondClock + self asMicroSeconds.
<br>> [Time utcMicrosecondClock >= proceedTime] whileFalse
<br>> 
<br>> [http://www.hpi.de/]
<br>> [1000 timesRepeat: [0.001 seconds busyWait]] timeToRun "--> 1000"
<br>> 
<br>> Much faster.
<br>> 
<br>> Could we need this in the Trunk, too?
<br>> 
<br>> Best,
<br>> Christoph
<br>> -------------- next part --------------
<br>> An HTML attachment was scrubbed...
<br>> URL: <http: lists.squeakfoundation.org="" pipermail="" squeak-dev="" attachments="" 20210701="" 8b74281c="" attachment.html="">
<br>> 
<br>> 
<br></http:></christoph.thiede></div></blockquote></div>