<br><br><div class="gmail_quote">On Thu, May 7, 2009 at 10:11 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div style="word-wrap:break-word"><div><div>On 07.05.2009, at 18:53, Eliot Miranda wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Thu, May 7, 2009 at 9:36 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> 2009/5/7 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>>:<br>
<div><div></div><div>>I intend to add immediate characters within the next few months.<br> ><br> </div></div>so, does that means that you will extend the oop tag to 2 bits (or more)?</blockquote><div><br></div><div>
Yes. Keep 31-bit SmallIntegers, provide e.g. 24-bit immediate characters. Andreas wrote a <a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2006-January/000429.html" target="_blank">thorough sketch of this scheme</a> in 2006.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Or just reserve a non-movable heap space for character objects, like:<br> isCharacterObject: oop<br> ^ oop >= charsStart and: [ oop < charsEnd ]</blockquote>
<div><br></div><div>No. This doesn't scale to unicode. The tagged approach provides much faster string access, and identity comparison for all characters, not just the byte range.</div></div></blockquote><br></div><div>
Do we have evidence that Character allocation is an actual performance bottleneck?</div></div></blockquote><div><br></div><div>The problem is not so much character allocation because by far the most character access in e.g. IDE usage is with byte characters. The problem is character indirection. To assign a character to a string in ByteString>>at:put: requires indirecting through the character to extract the character code. To answer a character in ByteString>>at: involves indirecting through the specialObjectsOop to fetch the characterTable and indexing the character table with the byte character code. But allocation is very slow in Squeak so for Unicode the problem for at: is much worse because we also have to allocate the result box. </div>
<div><br></div><div>This is very slow compared to merely adding/removing a tag bit. As for evidence as to whether this is a bottle-neck it is obscured by plugin primitives that mitigate the effects, such as primitiveFindSubstring. In general these are a bad idea because they're hard to debug, effectively impossible to change and are not polymorphic. But take a look at the following, which uses identityIndexOf: to avoid primitive machinery (but is no slower since invoking the primitive machinery is in itself expensive)</div>
<div><br></div><div><div><div>| wa ws ba bs bc wc n |</div><div>ba := (120 to: 125) collect: [:cc| Character value: cc].</div><div>bs := ba asString.</div><div>bc := ba last.</div><div>wa := (12345 to: 12350) collect: [:cc| Character value: cc].</div>
<div>ws := wa asString.</div><div>wc := wa last.</div><div>n := 1000000.</div><div>{ Time millisecondsToRun: [1 to: n do: [:ign| ba identityIndexOf: bc ifAbsent: 0]].</div><div> Time millisecondsToRun: [1 to: n do: [:ign| bs identityIndexOf: bc ifAbsent: 0]].</div>
<div> Time millisecondsToRun: [1 to: n do: [:ign| wa identityIndexOf: wc ifAbsent: 0]].</div><div> Time millisecondsToRun: [1 to: n do: [:ign| ws identityIndexOf: wc ifAbsent: 0]] }</div><div>Squeak 4.0 beta1 Closure:<span class="Apple-style-span" style="white-space: pre; "> <span class="Apple-style-span" style="white-space: normal; ">#(448 1058 451 8631)</span></span></div>
<div><div>Stack VM:<span class="Apple-tab-span" style="white-space:pre"> </span>#(581 1531 579 7303)</div>
<div>Cog:<span class="Apple-tab-span" style="white-space:pre"> </span>#(214 600 213 1970)</div><div><br></div></div><div>So string access is two to three times slower than array access when the result is fetched from the character table and an order of magnitude worse when the result must be boxed. (I don't know why the Stack VM is slower than Squeak 4 for non-boxed access; I probably need to do a merge :) ).</div>
</div><div><br></div><div><br></div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><br><div> <span style="border-collapse:separate;border-spacing:0px 0px;color:rgb(0, 0, 0);font-family:Lucida Grande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<div style="font-family:Helvetica"><span style="font-family:Helvetica">- Bert -</span></div><br></div></span> </div><br></div><br></blockquote></div><br>