<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Ronie,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 21, 2020 at 5:48 PM Ronie Salgado <<a href="mailto:roniesalg@gmail.com">roniesalg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>That performance regression looks more like a language implementation bug that a problem of the language itself. If we assume that #do: and some other selectors (e.g. #select, #reject) should always receive a block instead of a symbol, then the compiler could perfectly replace the symbol literal for an already instantiated block literal transparently from the user perspective. If the compiler does that we can save the bytecode for instantiating the block closure, which can save a potential roundtrip to the garbage collector. I guess (I am just speculating) that this performance overhead must be in the implementation of the #perform: primitive, which I guess has to:</div><div>1) go through the JIT stack into the C stack transition (saving/restoring interpreter/JIT state, additional pressure, and primitive activation overhead.<br></div></div></blockquote><div><br></div><div>perform:, perform:with: et al (primitive 83), but not perform:withArguments: are completely implemented in machine code with no transition to C unless the method is not in the first-level method lookup cache.  See  genPrimitivePerform, genLookupForPerformNumArgs: and adjustArgumentsForPerform:.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>2) the lack of inline caches for #perform: (again, I am just guessing in this case).</div></div></blockquote><div><br></div><div>Right.  There is only the first level method lookup cache so it has interpreter-like performance.  The selector and classs of receiver have to be hashed and the first-level method lookup cache probed.  Way slower than block activation.  I will claim though that Cog/Spur OpenSmalltalk's JIT perform implementation is as good as or better than any other Smalltalk VM's.  IIRC VW only machine coded/codes perform: and perform:with: </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Note that the OpalCompiler is currently inlining some methods such as #ifTrue:ifFalse: ,  #ifNil:ifNotNil: #and: #or: and there are not actual message sends, so adding an additional list of selector where literal symbol arguments are synthesized as blocks is not different to the cheating that the current compiler is doing. If an user wants to disable this inlining, there is currently a pragma for telling the compiler.<br></div><div><br></div><div>Do you want me to propose an experimental patch for testing this infrastructure?<br></div><div><br></div><div>Best regards,</div><div>Ronie<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mar., 21 ene. 2020 a las 19:56, Sven Van Caekenberghe (<<a href="mailto:sven@stfx.eu" target="_blank">sven@stfx.eu</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">I also like the use of symbols but more for casual code.<br>
<br>
I know using blocks can be faster, but the difference is not massive.<br>
<br>
What I don't understand is why it is so super bad. Polymorphism will always be there, that is really powerful, when used wisely. I can't immediately see why one or the other would make analysis easier or better. Can you explain ?<br>
<br>
> On 21 Jan 2020, at 23:37, Sean P. DeNigris <<a href="mailto:sean@clipperadams.com" target="_blank">sean@clipperadams.com</a>> wrote:<br>
> <br>
> ducasse wrote<br>
>> in Pharo we should write     <br>
>>      aCol do: [ :each | each store ]<br>
> <br>
> I always enjoyed the Symbol/Block polymorphism because I thought it was such<br>
> a clever and visible example of the power of Smalltalk, and, let's face it,<br>
> I'm lazy and enjoyed saving a few key strokes! <br>
> <br>
> That said, I had no idea that there was a dramatic performance cost. Also,<br>
> the issues you raise about analysis seem important.<br>
> <br>
> Since people are free to still use it in their own projects, it doesn't seem<br>
> to controversial. Can/should we add a lint rule? Can/should it be scoped to<br>
> Pharo core?<br>
> <br>
> <br>
> <br>
> -----<br>
> Cheers,<br>
> Sean<br>
> --<br>
> Sent from: <a href="http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html" rel="noreferrer" target="_blank">http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html</a><br>
> <br>
<br>
<br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div></div>