<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>  <br>
>       I don't think we would want to do that without measuring the effects of<br>
>       the change somehow.<br>
> <br>
> <br>
> Performance measuring is already part of every system that cares, right?   :)<br>
<br>
Of course not. That's why "somehow" is there. I don't know how it could be <br>
measured, but I think that without measurements, it's risky to change <br>
something like that.<br></blockquote><div><br></div><div>You should be careful, Levente, Collections-ul.871 does it, too.  Everywhere #new: 1 or #new: 2 occurs, you've reduced the internal array size from 5 to 3.  And, yes, it did indeed introduce this unexpected anomaly!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> None of those systems are depending on any particular default initial size for performance.  If they are, they should be fixed.<br>
<br>
Here is an example scenario:<br>
I write my code. I use [OrderedCollection new]. I see that my code is fast <br>
enough.<br>
You change the default capacity from 10 to 3. My code is now too slow. I <br>
have to profile it to see why. It turns out that I store 7-9 elements most <br>
of the time, and the capacity of 10 was a good fit, but 3 is not, because <br>
it means growing twice (first to 6, then to 12), and my code ends up <br>
being slower and using more memory than before.<br></blockquote><div><br></div><div>This example makes the case for this proposal, by showing that it was *depending on knowing the private, internal initial size*, for its performance.  By having written #new instead of #new: in performance-critical code, it was and still is less efficient than it could be.  No amount of "guessing" of an initial size will help execution performance, but could at least guarantee space efficiency.</div><div><br></div><div>More importantly, to me, it brings clear, definitive responsibility to #new: over #new.  <u>Efficiency</u>.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>  <br>
><br>
>       Same applies to OrderedCollections.<br>
><br>
>       Following your reasoning, the optimal initial capacity for any dynamic<br>
>       collection created with #new should be 0, but that doesn't feel right...<br>
> <br>
> <br>
> Not 0, 3.  It's "reasoning", not extremism.  :)<br>
> <br>
> 3 would be a great default for OrderedCollection.  Ultra-minimal, but with a purpose.   I mean, really, with 10, we have 92% of all instances wasting space.<br>
<br>
"Wasting space" is a must when you implement dynamic arrays and <br>
hash tables. It's a space-time tradeoff[1].<br></blockquote><div><br></div><div>OrderedCollection isn't hashed.</div><div><br></div><div>If we want have a sliding-scale trade-off between space and performance, so that "Dictionary new" everywhere in the code could be treated to run time or space-efficiently, that'd be something I could respect.  We'd need to introduce some kind a variable or PoolDictionary constant to allow a developer to customize, for the entire image, all cases of "Dictionary new" to run space-efficiently (e.g., on a 1GB RPi) or time-efficiently.</div><div><br></div><div>But we should not break #new: 1 and #new: 2 for HashedCollections, please.</div><div><br></div><div> - Chris</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Levente<br>
<br>
[1] <a href="https://en.wikipedia.org/wiki/Space%E2%80%93time_tradeoff" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Space%E2%80%93time_tradeoff</a><br>
<br><br></blockquote></div></div>