<div dir="ltr"><div dir="ltr">Hi Jakob,</div><div dir="ltr"><br></div><div>My main reply is in the other one to you and Levente, but some quick responses here for minor embellishment.  :)</div><div dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jan 25, 2020 at 3:21 AM Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank">forums.jakob@resfarm.de</a>> wrote:<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 dir="ltr">Am Sa., 25. Jan. 2020 um 06:55 Uhr schrieb Chris Muller <<a href="mailto:ma.chris.m@gmail.com" target="_blank">ma.chris.m@gmail.com</a>>:<br></div><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"><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">Here is an example scenario:<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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></div></blockquote><div><br></div><div>If you optimize the default for space instead of sticking with a reasonable tradeoff,</div></div></div></blockquote><div><br></div><div>"reasonable tradeoff" is what I'm trying to convince you is completely baseless.</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"><div dir="ltr"><div class="gmail_quote"><div> you might force people to use new: and think about the very implementation details of those collections to get back to reasonable results. </div></div></div></blockquote><div><br></div><div>Its no different than we have now.  Thinking about the size wherever you can is a good thing.</div><div><br></div><div>Your fear of changing #new is because of the fuzziness of its definition.  What you're calling "reasonable" is actually just "random".  If it were definitive (e.g., space-efficient), the impact of changing it would be, too.</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>You might turn a piece of code into a bottleneck even though it was not considered performance-critical before. </div></div></div></blockquote><div><br></div><div><div>Or it might rescue a suffering application because it's no longer paging RAM out to disk...  :)</div><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>On the other hand, who else was bothered by too sparse hashed or ordered collections until now? </div></div></div></blockquote><div><br></div><div>It's about designing the most-efficient system and the best API, not who has been bothered yet.</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"><div dir="ltr"><div class="gmail_quote"><div>Is it a problem that bothers many, in comparison to the group which the change could bother?<br></div></div></div></blockquote><div><br></div><div>What happens to that group when they move their code to another Smalltalk which uses a different default?</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>I suppose this is premature optimization. If people have identified compactness as a requirement,<br></div></div></div></blockquote><div><br></div><div>When all else is equal, more compact is <u>always</u> better than less.</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"><div dir="ltr"><div class="gmail_quote"><div>they shall use #new: with (domain specific) expected numbers or patch #new for their application. But don't force it on everyone. </div></div></div></blockquote><div><br></div><div>Patching #new and then using it because you patched it is a ridiculous suggestion.  That's what #new: is for.  This is about Squeak, not any one app..  10 is currently "forced" on everyone, and with 92% of OrderedCollections in trunk over-allocated, a smaller choice might be better...</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"><div dir="ltr"><div class="gmail_quote"><div>You wouldn't like me to submit a "performance optimization" that changes the new default capacity to 100 because my application happened to deal with collections of that size frequently and because memory is comparably cheap and large nowadays, would you?</div></div></div></blockquote><div><br></div><div>It's no less arbitrary than 10.  Both guarantee nothing.  At least 1, 2, or 3 guarantees space efficiency, and guarantees to make the API more definitive.</div><div><br></div><div>#new is fuzzy.  The whole reason you're worried about uses of #new being affected at all is because of that fuzziness.  We should give it clarity, make it definitively space-efficient...</div><div><br></div><div>The core library cannot <u>possibly</u> guess the shape of people's domains.  Our attempts to do so are causing more harm than good..</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"><div dir="ltr"><div class="gmail_quote"><div>We can only really know the impact if we have a benchmark or even an idea of realistic average collection usage. Maybe someone wrote a paper about that...</div></div></div></blockquote><div><br></div><div>The beginning of a dev cycle is where such a change can be implemented, leaving plenty of time for testing.</div><div><br></div><div>> Couldn't it be faster to use an OrderedCollection instead of a hashed one for such small numbers of elements? If the hash computation outweighs the linear search...</div><div style="margin:0px;padding:0px 0px 20px;width:1120px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:medium"><div><div id="m_-4710205979975392433gmail-:2g9" style="font-size:0.875rem;direction:ltr;margin:8px 0px 0px;padding:0px"><div id="m_-4710205979975392433gmail-:tn" style="overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial,Helvetica,sans-serif"><div></div><div>As mentioned, this is about Squeak system efficiency and API design, not any one specific app.</div><div><br></div><div> - Chris</div><div><br></div></div></div></div></div></div></div>