[squeak-dev] Re: The defaullt implementation of isEmpty might do too much work

Chris Muller asqueaker at gmail.com
Wed Oct 26 04:42:24 UTC 2016


I agreed that it looked good in the ivory tower.  The thing is, there
are these real-world detractors which we should not igore.  To save my
old fingers, let me just summarize them from the earlier posts.  In
summary:

  - it provides no known material benefit
  - it could affect unsuspecting legacy application performance
materially, and in an insidious way
  - it's an anomalous usage of the API which works against performance
expectations about #size and #do:.
  - the justification for this change (performance optimization) in
Collection is not valid in the first place.

No real-world positives, just negatives or zeros.  Please revert.

On Tue, Oct 25, 2016 at 6:42 PM, David T. Lewis <lewis at mail.msen.com> wrote:
> On Sat, Oct 22, 2016 at 12:59:48AM +0200, monty wrote:
>> All non-trivial collections implement #size or inherit a custom implementation, usually just as a return of an inst var. Your #do:-based one is 3x as slow in my tests, so you've now made #isEmpty slower for every collection that implements #size just to benefit ones whose careless authors didn't and so the implementors of lazy collections have one fewer message to override.
>>
>> Do not do this. People already avoid #ifEmpty: and related messages where performance matters and shouldn't have to avoid #isEmpty too.
>
> I like Eliot's new implementation, in part because it teaches the reader something
> about how iteration works. It is still simple enough for an inexperienced person
> to read, but it also challenges the reader to think about the control flow.
>
> That said, I suspect that Monty and Chris are among the people with the most
> real-world experience in dealing with performance on very large collections.
>
> So, I would like to ask from a strictly practical point of view, does the change
> that we are discussing here cause real-world problems for Gemstone and Magma
> applications?
>
> Does the change make the maintenance of large collection classes more difficult
> for cross-dialect portability?
>
> Are there any collection classes (especially in Gemstone and Magma) that become
> slower in a real-world measurable sense as a result of this change?
>
> Dave
>
>


More information about the Squeak-dev mailing list