<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 25 Mar 2021, at 16:26, Maria Scott <<a href="mailto:maria-12648430@hnc-agency.org" class="">maria-12648430@hnc-agency.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi,<br class=""><br class="">not sure about cheap, but...<br class=""><br class=""><blockquote type="cite" class="">But, Culpa Mea — I should have formulated my question a bit better.<br class="">Thus, let me take another stab at it: what would be more efficient, canceling the timer (and thus avoiding generation of the message), or letting the send_after/3 generating (and runtime delivering) the message?<br class="">The answer should be considered relative to the "event ordering" process — will it spend more time canceling the message, or removing generated message from its queue)?<br class=""></blockquote><br class="">... it may happen that the timer expires and sends the message just before you cancel it. The message will then pollute your message queue. As such, you should react on the return of cancel_timer/1, if it returns false you may want to flush out that message.<br class=""><br class="">But on another note, erlang:cancel_timer/1 is synonymous to erlang:cancel_timer/2 with options {async, false} and {info, true}, which results in a blocking operation that will wait for the cancellation to really "happen". You may look into option {async, true}, which will immediately return ok and not block the calling process. You will still have to take care of the possible message that may have been sent just before you cancelled the timer.<br class=""><br class="">Kind regards,<br class="">Maria Scott<br class=""></div></div></blockquote></div><div class=""><br class=""></div><div class="">Thank you, Maria</div><div class=""><br class=""></div><div class="">All things considered, it appears to be “cheaper" <b class="">not to</b> <b class="">cancel</b> the timer (and thus generated event) when the timer values for are reasonably small (e.g. a few seconds), but desirable to <b class="">do so</b> (as Jasper suggested), when values for the timer are relatively high (in order to provide for a better memory utilisation used by erlang:send_after/3 scheduler). </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Kind regards</div><div class=""><br class=""></div><div class="">V/</div><div class=""><br class=""></div></body></html>