<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
                                        
                                        
                                            
                                        
                                        
                                        > <span style="font-family: Arial, Helvetica, sans-serif;font-size: 13px">Is eager initialization out of the question for you?</span><div class="mb_sig"></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">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?</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><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 21.07.2020 12:07:44 schrieb Jakob Reschke <forums.jakob@resfarm.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">Hi Marcel,<br><br>Might be cool if the JIT or Scorch emitted code that is equivalent to<br>a quick return, but with a low-level nil-guard in place. Like a<br>quick-return-if-not-nil primitive code.<br><br>Is eager initialization out of the question for you?<br><br>If all your instVars were initialized on the first read of one of<br>them, you could also change the class of the object after the lazy<br>initialization, and the new class would have quick accessors. For<br>added fanciness, you could auto-generate the "optimized" class and<br>such accessors in both classes. Though I am totally not sure whether<br>it is worth the effort or improves the performance at all (since the<br>call sites are then polymorphic).<br><br>notYetInitialized: sounds strange to me, since you could send the<br>getter in one place and actually use the answer in a totally different<br>place (where your MNU happens). You could eager-initialize and return<br>some special case proxy instead of nil that is bound to the original<br>receiver and takes care of the lazy initialization when called.<br><br>Kind regards,<br>Jakob<br><br>Am Di., 21. Juli 2020 um 10:36 Uhr schrieb Marcel Taeumel<br><marcel.taeumel@hpi.de>:<br>><br>> Hi all!<br>><br>> 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.<br>><br>> 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 ...<br>><br>> (Why? Performance reasons for a little project of mine.)<br>><br>> Best,<br>> Marcel<br>><br><br></marcel.taeumel@hpi.de></div></blockquote></div>