[squeak-dev] Re: The defaullt implementation of isEmpty might do
too much work
Bert Freudenberg
bert at freudenbergs.de
Wed Oct 26 16:35:42 UTC 2016
On Wed, Oct 26, 2016 at 6:42 AM, Chris Muller <asqueaker at gmail.com> wrote:
> 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
>
Having an O(1) runtime vs O(n) is a very large material benefit.
Collection>>size is O(n) so it's not a good base for #isEmpty.
> - it could affect unsuspecting legacy application performance
> materially, and in an insidious way
>
If you have performance problems, profile.
> - it's an anomalous usage of the API which works against performance
> expectations about #size and #do:.
>
The performance expectation of both #size and #do: in Collection is O(n).
And there is nothing "anomalous" in using #do:, quite to the contrary, #do:
is the *essence* of a collection of objects.
> - the justification for this change (performance optimization) in
> Collection is not valid in the first place.
>
It is very valid optimization given the implementation of Collection>>size.
> No real-world positives, just negatives or zeros. Please revert.
>
Quite the opposite. It's a major improvement in basic API.
Yes, you will have to provide an optimized #isEmpty now, because you relied
on an implementation detail of a superclass. But there never was a
contract that #isEmpty needs to be implemented in terms of #size. The new
implementation makes much more sense for an arbitrary abstract Collection,
so I'd like to see it stay.
- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20161026/b37629dc/attachment.htm
More information about the Squeak-dev
mailing list
|