<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-11-23 8:04 GMT+01:00 Clément Bera <span dir="ltr"><<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>No.  The perform: primitive is in machine code and probes the first-level method lookup cache.  If it finds a hit it either jumps to the entry point (if the method is fitted) or enters the interpreter (if the method is not).  The issue here is that the cache needs to be at the send site, but there is nothing special about the #perform:[with:*] selector. Whether the send is a perform or not depends on the send binding to a method containing as perform: primitive.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>In addition to receiver class it could also check selector from argument.</div></div>
</blockquote></div><div class="gmail_extra"><br></div>What exactly do you mean here?<br></div></div></blockquote><div><br></div><div>Hi,</div><div><br></div><div>I think he's talking about Stefan Marr optimisation. For perform, you could have a first inline cache at send site, and when finding the perform primitive, instead of relinking to the machine code of perform, it would create a second PIC-like cache which compares again already met selectors and directly dispatch to the method to be performed. It would move perform cache from a global cache in the primitive to per send site caches, speeding up perform. In addition, the Sista optimiser could read the selector information.</div></blockquote></div><br>Yes, exactly. </div></div>