<div dir="ltr"><div dir="ltr">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div></div></div></blockquote><div>Hi Chris,</div>
</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 29 janv. 2020 à 09:39, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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></div></blockquote><div>
<div><br></div><div>Hmm not sure about that. Not for single or few objects.<br></div><div>Allocating many larger short lived objects will increase the rate of scavenging statistically, but this will be measurable only is allocating massively this kind of objects IMO.<br></div><div><br></div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></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 <br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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></div></blockquote><div><br></div><div>Typical Smalltalk objects are short lived.</div><div>That's why we get a generational garbage collection.</div><div>So typical usage is unlikely to generate paging.</div><div>Case of paging can only occur if many of these objects are longer lived (and tenured), which again is not typical.</div><div>For specific usage, there might be specific optimizations like growing a bit the Eden.<br></div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></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></div></blockquote><div><br></div><div>All your analysis is exclusively focused on
a specific un-typical usage of the library...</div><div>You are then trying to bend the general purpose library tothis specific case.</div><div>IMO this should be handled with a specific optimization.</div><div><br></div><div>I did propose using something like a SmallDictionary that is WAY more optimized for small size than hashed collection.</div><div>If not all your dictionary are small, you could have a subclass that switch (becomeForward:) representation when needing to grow.<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"><div dir="ltr"><div class="gmail_quote"><div></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></div></div></div></blockquote><div><br></div><div>IMO this is typical biased usage of percentages...</div><div>Saving 30% of a short duration or 30% of a long duration is not at all the same thing!</div><div>The former case is premature optimization presumably unless used in tight loops.<br></div><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"><div dir="ltr"><div class="gmail_quote"><div></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>
<br>
</blockquote></div></div>