[squeak-dev] The Trunk: Collections-eem.792.mcz

karl ramberg karlramberg at gmail.com
Thu May 3 20:09:53 UTC 2018


I'm all for faster code in the standard library.
One could leave the old version in the comment as an example for other ways
of writing it.

Best,
Karl


On Thu, May 3, 2018 at 7:51 PM, Chris Cunningham <cunningham.cb at gmail.com>
wrote:

>
>
> On Thu, May 3, 2018 at 10:34 AM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>>
>>
>> On Thu, May 3, 2018 at 10:12 AM, Chris Muller <asqueaker at gmail.com>
>> wrote:
>>
>>> +1.  Not only that, why the call to #basicSize and #basicAt:.  Really?
>>>
>>> It's like...  not even Smalltalk anymore...   :(
>>>
>>
>> What?  This is a workhorse method, and you want to create a block, and
>> apply the block to each element, and convert each element from a character
>> to an integer, when basicAt: yields (and has always yielded) integers in
>> strings?  You think that one line with a block and a high-level iterator is
>> so much better than a two line with a simpler inner loop?
>>
>> | strings nothing allSatisfy basicAt |
>> strings := String allSubInstances.
>> strings := strings, strings, strings, strings, strings.
>> nothing := [:s|].
>> allSatisfy := [:s| s isAsciiStringWithAllSatisfy].
>> basicAt := [:s| s isAsciiStringWithBasicAt].
>> Smalltalk garbageCollect.
>> 1 to: 2 do:
>> [:ign| times := { nothing. allSatisfy. basicAt } collect: [:block|
>> [strings do: block] timeToRun]].
>> (times second - times first / (times third - times first) asFloat)
>> roundTo: 0.1
>>
>> Answers range from 5.1 to 5.7 on 64-bits Mac OS X.
>>
>> You really want that elegance for something that is 5 times slower but
>> one line shorter?  I did this because I saw Patrick inline isAsciiString in
>> mail message processing, and I thought a) his method would read better if
>> it used isAsciiString, and b) isAsciiString can be implemented much better
>> without affecting clients, so I went ahead.  Part of the beauty of
>> Smalltalk is that clients are insulated from implementation so that
>> implementations can be improved.  Since when has that not been a part of
>> Smalltalk?
>>
>> While I understand (and like) the idea of having nice, clean, elegant
> methods everywhere in Squeak, I also would like it to be super fast.  I
> think Eliot's change is a nice example straddling that line - note the
> elegant way, and then show (and implement) a fast way to do the same thing
> still just using Smalltalk.
>
> Not to mention that he actually commented the method with what it should
> do.
>
> -cbc
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180503/5805edfe/attachment.html>


More information about the Squeak-dev mailing list