[squeak-dev] The Inbox: Collections-cmm.874.mcz

Jakob Reschke forums.jakob at resfarm.de
Wed Feb 5 08:59:28 UTC 2020


Chris Muller <asqueaker at gmail.com> schrieb am Di., 4. Feb. 2020, 04:39:

>
> I still don't see a compelling reason to change #new.
>>
>
> Levente's proposal changes it.  That's what sparked this whole
> conversation...
>

Your commit at the top of this thread changes the default capacity and that
is what we are writing about.

 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.
>

I think the analogy is flawed. There is a space/time tradeoff with the size
of the preallocated array. I see no such thing with Dictionary>>at:. Also
new allows its user to defer a decision/analysis, at: does not.


>
>>
>> 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.
>

No, not at all! They are relevant since we are discussing about new and the
default capacity, not new:.

Also you saying 99% of my cases are not worthy of the performance they used
to have... does not sound appealing to me.

>
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.
>

"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."

Not quite man page length, but seems adequate to cover my expectations.


>
>>
>> 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..
>

What is that supposed to mean? Do you think the Java designers renamed
almost all of the classes and methods, rewrote all of the documentation,
but forgot to think about changing the initial capacity of ArrayList ex
OrderedCollection?

In fact they did change something about it in Java 8 as I found out after
my last post: initially the array is empty (singleton), but it still
allocates 10 slots once the first element is added. This optimizes space
for empty  collections, but not small ones.


>
>>
>> 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.
>

If I use new: to optimize performance I am fairly certain that it won't
grow afterwards. My original statement still stands.


>
>> 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.
>

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. For collections that are supposed to grow
automatically. Slowing down developent of even non-performance-critical
parts. I don't want that either.

Changing the current behavior can make it worse for existing applications
(again: we lack the numbers to be sure of the contrary). Keeping the
current behavior is bad with regards to your concerns. I say: let's
therefore not change it, since user code has already been written and most
of it is unlikely to be improved again.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200205/4214e522/attachment.html>


More information about the Squeak-dev mailing list