To optimize, or not to optimize
Typically, one does not care much about the implementation of things such as OrderedCollection. They are so commonplace that it is safe to assume they work because otherwise the whole system would crash.
It is here that sometimes one finds the opportunity to optimize code. Take for example OrderedCollection>>addAll:, implemented in terms of aCollection do: [:each | self add: each] in VisualWorks. There's nothing wrong with this, and actually it's kind of nice because it seems to show some double dispatch tendency, written in some beautifully lazy way.
Until addAll: starts showing up in the TimeProfiler. Then you wonder... why should range checks be performed for each invididual addition? Or why should the collection have to grow several times when the final size is already known?
Of course then you look at the implementation of addLast:, inline the range / grow check in addAllLast: and then send addLastNoCheck: instead. Voila, all that OrderedCollection nonsense is gone from the TimeProfiler.
But... the new implementation is harder to understand. Is that element count right in the grow check? And by how much should the collection grow? Just to self size + aCollection size? Or should it grow a bit more in anticipation of more additions? By how much? Ahhh... the hours of second-guessing this kind of stuff can create while increasing the cost of change...
So, given this background... if you were to improve addAll: as discussed above, should you propose that the improvement is included in VisualWorks' next release as an enhancement? Is the sometimes quite significant speedup worth the additional complexity?
Questions, questions.
