Smalltalk - Re: The Trunk: Collections-eem.792.mcz

Smalltalk › Squeak › Squeak - Dev

Re: The Trunk: Collections-eem.792.mcz

Posted by Squeak - Dev mailing list on May 03, 2018; 7:12pm
URL: https://forum.world.st/The-Trunk-Collections-eem-792-mcz-tp5075599p5075718.html

Are we really arguing about the use of #basicAt: and #basicSize right now ???? Really ? Really ?!?!?!?

These methods are there for one reason : speed. If we find them "confusing", we really got a problem!

There are 127 senders of #basicAt: and 125 senders of #basicSize in the current Squeak 6.0 image...

-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

On Thursday, May 3, 2018, 1:34:17 p.m. EDT, Eliot Miranda <[hidden email]> wrote:

On Thu, May 3, 2018 at 10:12 AM, Chris Muller <[hidden email]> 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?

On Thu, May 3, 2018 at 3:41 AM, Tobias Pape <[hidden email]> wrote:
> Hi Eliot
>
>> On 03.05.2018, at 09:56, [hidden email] wrote:
>>
>> Eliot Miranda uploaded a new version of Collections to project The Trunk:
>> http://source.squeak.org/ trunk/Collections-eem.792.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Collections-eem.792
>> Author: eem
>> Time: 3 May 2018, 12:55:52.175146 am
>> UUID: 7d8995ed-835e-44b0-bf4c- 0b0780f5c96f
>> Ancestors: Collections-pre.791
>>
>> Four times faster implementation of isAsciiString.
>>
>> =============== Diff against Collections-pre.791 ===============
>>
>> Item was changed:
>> ----- Method: String>>isAsciiString (in category 'testing') -----
>> isAsciiString
>> + "Answer if the receiver contains only ascii characters.
>> + Inline ^self allSatisfy: [ :each | each asciiValue <= 127 ] for speed."
>> + 1 to: self basicSize do: [:i| (self basicAt: i) > 127 ifTrue: [^false]].
>> + ^true!
>> -
>> - ^self allSatisfy: [ :each | each asciiValue <= 127 ]!
>>
>>
>
> Although I am in awe of the performance improvement, I am curious wether it really pays of to inline #allSatify: here, in terms of performance vs. readability.
>
> I presume that, given the current use of #isAsciiString, we can stay with the more compact, readable version that does not need the 'caveat lector'-comment at the beginning of the method.
>
>
> Best regards

> -Tobias
>
>

_,,,^..^,,,_

best, Eliot