[squeak-dev] MNU for ifNil: to preserve quick returns? :-)

Marcel Taeumel marcel.taeumel at hpi.de
Tue Jul 21 10:22:35 UTC 2020

> Is eager initialization out of the question for you?

Not quite. But saving 400 000 extra objects where each may have 5 to 10 instVars ... could be worthwhile if those are not used at all. I suppose that all instVars being "nil" is not optimized in the VM?

Am 21.07.2020 12:07:44 schrieb Jakob Reschke <forums.jakob at resfarm.de>:
Hi Marcel,

Might be cool if the JIT or Scorch emitted code that is equivalent to
a quick return, but with a low-level nil-guard in place. Like a
quick-return-if-not-nil primitive code.

Is eager initialization out of the question for you?

If all your instVars were initialized on the first read of one of
them, you could also change the class of the object after the lazy
initialization, and the new class would have quick accessors. For
added fanciness, you could auto-generate the "optimized" class and
such accessors in both classes. Though I am totally not sure whether
it is worth the effort or improves the performance at all (since the
call sites are then polymorphic).

notYetInitialized: sounds strange to me, since you could send the
getter in one place and actually use the answer in a totally different
place (where your MNU happens). You could eager-initialize and return
some special case proxy instead of nil that is bound to the original
receiver and takes care of the lazy initialization when called.

Kind regards,

Am Di., 21. Juli 2020 um 10:36 Uhr schrieb Marcel Taeumel
> Hi all!
> I can choose to initialize an instVar eagerly in #initialize or lazily in its accessor via #ifNil:. Yet, the latter requires me to change that accessor to something not being a quick return.
> Could there be a simple way to initialize an instVar on its first read access? Like a #notYetInitialized: callback to the instVar-holding receiver. Instead, we get an MNU on UndefiniedObject ...
> (Why? Performance reasons for a little project of mine.)
> Best,
> Marcel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200721/cdf824fa/attachment-0001.html>

More information about the Squeak-dev mailing list