I know that, but I'm talking about allocation speed, not access speed.
This #new: violates the expectations of your typical Smalltalk programmer,
they'll write code they think is optimized but, actually, is much much
slower.

Surely there's a faster way to come up with a next-higher
prime?  Certainly, that primes table seems unnecessarily large for this
purpose -- anyone creating a Dictionary with > 1M preallocated slots is a
special-case scenario we should not slow down the "normal" cases for...

 - Chris

On Tue, Dec 17, 2019 at 4:33 PM Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> wrote:

> Hi Chris,
> The purpose of good prime sizes is to accelerate random access at: and
> at:put:. So more ellaborate bench should be used to measure if worth.
>
> Le mar. 17 déc. 2019 à 23:02, Chris Muller <asqueaker at gmail.com> a écrit :
>
>> Hi all,
>>
>> I just noticed that attempting to optimize the creation of a Dictionary
>> or OrderedDictionary by specifying a pre-allocated size, actually slows the
>> system down more than not using this optimization.  In trunk, see?
>>
>> [Dictionary new] bench.        '26,300,000 per second. 38.1 nanoseconds
>> per run. 9.21816 % GC time.'
>>
>> [Dictionary new: 4] bench.       '3,560,000 per second. 281 nanoseconds
>> per run. 2.41952 % GC time.'
>>
>> So then I tried to debug it to see why, and I couldn't without my
>> Tools-cmm.926 patch currently in the Inbox for review.
>>
>>        Dictionary new: 4    "try to debug-it and step into"
>>
>> The whole purpose of #new: over #new is to increase the performance of
>> allocation when the minimum size is known in advance, but we seem to have
>> killed this goal by the cost of #goodPrimeAtLeast:.  Levente?
>>
>> Best,
>>   Chris
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191217/583b8a79/attachment.html>