<br><br><div class="gmail_quote">On Sat, May 5, 2012 at 1:46 PM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(neither alpine, nor imp/horde can quote your mail due to the empty first attachment added by gmail, sorry)<br>
<br>
Thanks Eliot for looking into this issue.<br>
<br>
Yes, endIndex is very useful. For example LargeIdentityDictionary uses dynamic arrays to store the keys and values. The first element is stored at the first slot and we know the index of the last slot where an element is stored. The slots after that index conatain nil. The endIndex parameter makes it possible to avoid searching those nils if the element is not in the dictionary and simplifies the code, because searching for nil doesn't need special handling.<br>
<br>
I'm not sure if it's okay to use #longAt: in the loop, because the receiver can be an object which stores bytes (e.g.: ByteString/ByteArray) and I'd expect that the primivite also works correctly in that case. This would also make it possible to replace the existing linear search primitive for strings with this primitive.</blockquote>
<div><br></div><div>Is it OK if the primitive fails for CompiledMethod and/or MethodContext or are you looking for good performance for these too, e.g. with the PointerFinder?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Levente<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>