<div dir="ltr"><div class="gmail_quote"><div>Hi Levente, hi Jakob,</div><div><br></div><div>Thanks for the interesting discussion. I'd like you to know, I'm not gung-ho about this change, but do think we should seriously consider it for the benefit of Squeak. I think the benefit is real, but deceptive.</div><div><br></div><div>It seems there are two dimensions to the decision:</div><div><br></div><div> - legacy / compatibility</div><div> - API design / user-expectations</div><div><br></div><div>I do respect your point about legacy, that writing #new has always meant you get something that can hold up to 10 elements before needing to grow, instead of only 3.</div><div>It "<u>sounds"</u> reasonable, but...</div><div><br></div><div>Here are some <u>certainties</u>:</div><div><br></div><div> - Allocating a 3 element array is quicker than allocating 10 element one.<br></div><div> - 3 element Array's take up less memory than 10 element ones</div><div> - consuming more RAM can lead to slowdowns due to paging or GC overhead</div><div> - In the worst possible case (e.g., doing it over and over and nothing else), adding 9 elements to an (OrderedCollection new: 3) is 72% the speed of adding 9 elements to an (OrderedCollection new: 10). see [1]</div><div><br></div><div>Here are some <u>uncertainties</u>:</div><div><br></div><div> - there may be some code somewhere creating many thousands of OrderedCollections (if it were only a few, it wouldn't be noticed)</div><div> - the many thousands are all created in a very short amount of time (if it were spread out over time, it wouldn't be noticed)</div><div></div><div> - it then stores 7-9 elements in most of the OrderedCollections</div><div> - in spite of all of the above, the author still wrote #new instead of #new:</div><div><br></div><div>Letting fear of such remote uncertainties dominate your decision even in light of those certainties brings paralysis. Squeak can hardly improve if such low-risk items can't even be attempted at the beginning of a development cycle, when applications will surely undergo testing before deploying to the next version of Squeak (5.4). Our community is small (low chance) and helpful (low impact).</div><div>___</div><div>That leaves the API discussion, which was mostly ignored, but is really the key. I would like to touch on this with some responses, below:</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">> 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!<br>
<br>
When one says [Dictionary new: 1] or [Dictionary new: 2], one expects to <br>
get a dictionary that can hold one or two elements, respectively.<br></blockquote><div><br></div><div><div>How many should one "expect" to get with #new? Because one reason you gave for not wanting to reduce the default size seems to be based on some "expectation" you have for it.</div><div><br></div><div>There should be only one: that it shouldn't be significantly faster than #new: 1. <u>Nothing else</u>.</div></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">
Collections-ul.871, just like the former version, creates dictionaries <br>
matching those expectations, but Dictionaries returned by the new version <br>
use less memory.<br>
So, what's the problem?<br></blockquote><div><br></div><div>It slowed down (Dictionary new: 1) relative to trunk, </div><div><b>by a comparable margin</b> as adding 9 elements to an (OrderedCollection new: 3) relative to an (OrderedCollection new: 10 </div><div>(see [1])</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">How often do you investigate the internals of classes your code uses to <br>
avoid relying on the default values coded into them</blockquote><div><br></div><div>The answer is already "never" right here...</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"> when there are no <br>
performance problems with your code? I guess never...<br></blockquote><div><br></div><div>... but I still want to write "optimized" code even _before_ having any "performance problems." Proactivity. :)</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">
> But we should not break #new: 1 and #new: 2 for HashedCollections, please.<br>
<br>
The performance difference between #new, and #new: X where X is <= 3, <br>
didn't bother you (or anyone else) until recently.<br></blockquote><div><br></div><div>Because the problem is in proposal Collections-ul.871, not trunk.</div><div></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">
I proposed all kinds of solutions to minimize the difference between #new <br>
and #new:, and we seemed to agree on one of those.<br></blockquote><div><br></div><div>Cool, let's do one of those, thanks!</div><div><br></div><div> - Chris</div><div> </div><div>[1] -- (adding 9 elements to OrderedCollection new: 10)</div><div> 100% of baseline rate, 3,860,000 per second. 259 nanoseconds per run. 2.88 % GC time.'</div><div><br></div><div> (adding 9 elements to OrderedCollection new: 3)</div><div> 72% of baseline rate, 2,790,000 per second. 359 nanoseconds per run. 3.55929 % GC time.</div><div><br></div><div> (Dictionary new: 1) in trunk</div><div> 21,800,000 per second. 45.9 nanoseconds per run. 13.8 % GC time.</div><div><br></div><div> (Dicitionary new: 1) with Collections-ul.871</div><div> '16,300,000 per second. 61.4 nanoseconds per run. 5.05899 % GC time.'</div></div></div>