[squeak-dev] The Trunk: Collections-eem.792.mcz
Benoit St-Jean
bstjean at yahoo.com
Thu May 3 19:12:21 UTC 2018
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 <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?
On Thu, May 3, 2018 at 3:41 AM, Tobias Pape <Das.Linux at gmx.de> wrote:
> Hi Eliot
>
>> On 03.05.2018, at 09:56, commits at source.squeak.org 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180503/c41f0d21/attachment.html>
More information about the Squeak-dev
mailing list
|