<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"><div dir="auto"><div class="gmail_quote" dir="auto"><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">try writing a manpage-quality comment for #new: explaining all the nuances...  when to use it, when not to, etc...  My hope that exercise would illuminate the issue I have.</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">"Allocate a new instance of me with the given initial capacity. Use new: instead of new if you want to avoid either unused capacity or repeated growing (and thus, copying) of the collection's memory."</div></div></blockquote><div><br></div><div>The goal of using #new: is efficiency in general, space OR time (or, both).  So w.r.t. the case of optimizing for time, you forgot to mention the 40% performance hit they would take if the size happened to be 1 or 2...</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="auto"><div dir="auto">Not quite man page length, but seems adequate to cover my expectations.<br></div></div></blockquote><div><br></div><div>Make a spreadsheet with the cartesian product of the following, one per row, and then manually fill out an extra column whether you'd write #new or #new:.</div><div><br></div><div>    (knows size | does't know size) </div><div>    * (knows at runtime | knows at compile time) </div><div>    * (will possibly grow | won't possibly grow)</div><div>    * ( ... | ...)</div><div><br></div><div>When designing a class libary, please think in these general terms and consider <u>all cases</u>, instead of only your own expectations.<br></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="auto"><div class="gmail_quote" dir="auto"><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"><div dir="auto"><div dir="auto">Also I don't expect that initial allocation with new: will always be faster. I expect that I can save reallocations later on. </div></div></blockquote><div><br></div><div>As I said before, not if you know your Dictionary will never grow.   This is not app-specific.</div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">If I use new: to optimize performance I am fairly certain that it won't grow afterwards. My original statement still stands.</div></div></blockquote><div><br></div><div>You said "fairly" certain, now please consider the case where it's <u><b>certain</b></u> never to grow (perhaps row 187 on the spreadsheet, above).  I gave you a common, concrete example in an earlier post.  That's the case where your incomplete manpage comment (under Collections-ul.871) could easily trick the developer into hurting her apps performance when she thought she was helping it.  You argued (with flawed logic) that people would have to "think about the sizes all the time" but that's exactly what this would introduce, except in a much more insidious way!  Because it affects negatively depending on the <u>runtime parameter</u> value passed to #new:.</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="auto"><div class="gmail_quote" dir="auto"><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"><div dir="auto"><div dir="auto">That is where the time is supposed to be saved. If new is faster than new: 1, I am fine with that.</div></div></blockquote></div></div></blockquote></div></div></blockquote><div><br></div><div>You say you're "fine" with that <u>certain</u> performance hit, but you're not fine with this uncertain one whose worst-case possibility was measured to be an equal performance cost.  <u>And</u>, you're even willing to trade away certainty of space-efficiency, 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="auto"><div class="gmail_quote" dir="auto"><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>This thread is about reducing the defaultSize.  The other thread is about #new:1 needing to be same speed as #new.  They're two separate discussions.  An API design that forces developers to trade one optimization for another is bad design, plain and simple.<br></div></div></div></blockquote></div><div dir="auto"><br></div><div dir="auto"><div dir="auto" style="font-family:sans-serif">Then the only sensible solution would be to deprecate and remove new for preallocating collections altogether. Forcing everyone to always think ahead of their collection sizes. </div></div></div></blockquote><div><br></div><div>Sigh.  With statements like the above, I wonder whether you're actually interested in finding a solution or simply arguing...  :(</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="auto"><div dir="auto"><div dir="auto" style="font-family:sans-serif">For collections that are supposed to grow automatically. Slowing down developent of even non-performance-critical parts. I don't want that either.</div></div></div></blockquote><div><br></div><div>This was your best argument, but it only takes about 10 seconds to understand its logical flaw -- if you're writing performance-critical code, you're going to write #new: anyway.  If you're not, an extra grow from writing #new won't affect performance.</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="auto"><div dir="auto"><div dir="auto" style="font-family:sans-serif">Changing the current behavior can make it worse for existing applications (again: we lack the numbers to be sure of the contrary).<br></div></div></div></blockquote><div><br></div><div>The worst-case scenario was benched and provided for you, and shown to be a similar effect as Collections-ul.871 on #new: 1.</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="auto"><div dir="auto"><div dir="auto" style="font-family:sans-serif">Keeping the current behavior is bad with regards to your concerns. </div></div></div></blockquote><div><br></div><div></div><div>As I said multiple times, the "current behavior" is <u>fine</u> to my concerns, Jakob, it was Levente's proposal which introduced them.  This was just one of two different solutions proposed, but you handily rejected them both, even while offering zero alternatives or even acknowledgement that my concerns are valid.  I'm going to cut my losses from this discussion now.  Your arguments seem like you either aren't understanding mine, or aren't willing to look for consensus.</div><div></div><div><br></div><div>Levente has committed Collections-ul.872 with only his other changes, e.g., excluding the one which introduced my concern.  He's a gentleman.  It's sad that our inability to resolve this petty squabble kept back his other improvements, which would've included  the ability to create minimally small Dictionary's with a minimum internal array size of 3 instead of 5.  :(</div><div></div><div><br></div><div> - Chris</div></div></div>