<div dir="ltr"><div dir="ltr">Em qua., 19 de jun. de 2024 às 12:34, Marcin Grzejszczak <<a href="mailto:marcin.grzejszczak@gmail.com">marcin.grzejszczak@gmail.com</a>> escreveu:<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">If I'm making the mistake that you can assume the equivalence of the two approaches and instead there should be dedicated support for either of them (like reactive and non reactive programming), I would like to hear that so that we can start planning the whole rewrite of the api (rewrite or adding new api).<br></div></blockquote><div><br></div><div>Consider this about virtual threads, which the Loom team is frequently seen explaining.</div><div>Typically, a "threads" application sets up a thread pool to intermediate the distribution of tasks to threads, allowing a seemingly unbounded task set to run onto a fixed size set of task processors.</div><div>If one finds-and-replaces this platform thread pool with a virtual thread pool, all else remaining exactly the same, expecting the performance to become better may lead to disappointment.</div><div>Virtual threads are not "same but better" threads; they are different threads, optimal for certain threading architectures, not optimal for others.</div><div>The mantra for virtual threads is "do not pool virtual threads".</div><div><br></div><div>Consider this about ScopedValues.</div><div>One of the optimizations that the proposed design allows is caching.</div><div>Because, from the perspective of a "call scope", the result of ScopedValue.get is idempotent, the implementation is allowed to cache this value.</div><div>One may even hope that the VM would optimize out getter calls in hot code, if not this day then some day.</div><div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>