<div dir="ltr"><div dir="ltr">Hi Christoph,</div><div dir="ltr"><br></div><div>Thanks for the review and excellent suggestions.  Please see Collections-cmm.1019, and let me know if you see anything else.</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="m_2177935767918603046m_-6723465333348670102m_-791392088193415052m_-9073926800051867141gmail-m_476247262360230086x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><p><span style="font-size:12pt">Regarding the implementation: Did you run any benchmarks and how massive is the slowdown? The previous implementation used #basicAt: to avoid comparing characters (which is not fast on all platforms) and sending messages to them (in favor of inlining). I'm
 curious whether this could be avoided in the new implementation as well and how much performance could be won with that. #</span><span style="font-size:12pt">numberOrValue also looks very slow. Maybe it would be worth providing two alternative branches depending on the type of the collection argument?</span></p></div></div></div></blockquote><div><div>I tend to weigh toward a system defined tersely in terms of its own messages, and letting performance emanate from the _design_, as opposed to chasing an extra 5% of execution performance improvement at the expense of expressivity of the code.  If the point of that 5% is to "save time", it seems reasonable to consider the time of future readers of the code.</div></div><div><br></div><div>The method, #isAlphanumeric, is a prime example.  Originally, its implementation beautifully matched its definition.<br></div><div>_____</div><div>    isAlphaNumeric<br>        "Answer whether the receiver is a letter or a digit."</div><div>        ^self isLetter or: [self isDigit]<br></div><div><div>_____</div><br></div><div>Compare that to now, a complex, copy-and-pasted "implementation" which is a lot harder to understand and maintain, but only 10% faster in execution.  IMO, that seems past the point of diminishing returns of what a user of Smalltalk would expect.</div><div><br></div><div><div>Having said that, Squeak's speed is sweet, I can appreciate the desire to hyper-optimize at the bytecode level.  Here's Marcel's benchmark with the latest:</div><div>___</div><div>['Hello {1}!' format: { 'Squeak' }] bench.<br><br> '3,450,000 per second. 290 nanoseconds per run. 1.35946 % GC time.'   <--- new<br> '3,820,000 per second. 262 nanoseconds per run. 4.22 % GC time.'     <--- old<br><br>3450.0/3820   0.9031413612565445 <br></div>___</div><div><br></div><div>Looks like about a 10% hit for this example.  Maybe it could be improved, but I doubt by very much.  Unfortunately using #basicAt: isn't convenient when alphanumeric tokens are possible.  </div><div><br></div><div>If this is still too much, let me know, I'll take it back to the original numerals-only version.</div><div><br></div><div>Best,</div><div>  Chris</div></div></div>