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