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>