Hi Jakob,

I still don't see a compelling reason to change #new.
>

Levente's proposal changes it.  That's what sparked this whole
conversation...


>
> In one paragraph you write about using new: "proactively" and in the next
> you write this is not about performance.
>

The "proactively" was only in response to Nicolas and you talking about
"premature optimization", which was wrong.  When you say:

I only use new: when I know that it gives me a better result, after I
> noticed that I need a better result. "Proactive" from the start implies
> premature optimisation for me.
>

it's like saying, "Writing Dictionary>>#at: optimally before my application
suffers performance problems is 'premature optimization'."  Totally wrong.


>
> My opinion on the API: if I start out with no specific knowledge about the
> expected size of my collection or I don't think that is relevant, I use
> new.  That is 99% of the cases.
>

Those cases are irrelevant.  The cases we're discussing are the ones when
the size is known at runtime.


>
> I expect that the standard library gives me a default that has proven to
> work well in most cases. By "work well" I predominantly think of
> time-efficiency, not space-efficiency.
>

That sounds personal.  One thing that may help is what I suggested to
Levente, 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.


>
> We can look at other such libraries, OpenJDK also uses 10 for ArrayList:
> http://hg.openjdk.java.net/jdk/jdk/file/9211f6e20448/src/java.base/share/classes/java/util/ArrayList.java#l118
>
>
Java based its core library off Smalltalk, Jakob..


>
> Also I don't expect that initial allocation with new: will always be
> faster. I expect that I can save reallocations later on.
>

As I said before, not if you know your Dictionary will never grow.   This
is not app-specific.


> That is where the time is supposed to be saved. If new is faster than new:
> 1, I am fine with that.
>

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.  Levente's other
changes in Collections-ul are good, but to introduce a needless API
regression is pointless, and not okay.  We would need one solution or the
other.

 - Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200203/ee75ef16/attachment.html>