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

Levente Uzonyi leves at caesar.elte.hu
Sun Jan 5 08:12:35 UTC 2020


Hi Chris,

The problem with reverting #sizeFor: is that compaction will not be able 
to go below capacity 5, so capacity 3 (suitable for collections of size 0, 
1 or 2) would not be available ever.

On Sat, 4 Jan 2020, Chris Muller wrote:

>
>       So, back to my "problem", it looks like I'm safe to write:
> 
>       Dictionary new: runtimeVar
> 
> and, no matter what size, there will never be a performance hit over Dictionary new.  Whew!

As we discussed before, the allocation cost of #new: can not be lower than 
the cost of #new, because #new has a hardcoded prime value, while #new: 
has to calculate a good prime. But filling up the object created by #new 
will be slower than the one created by #new: when you want to store more 
than 3 elements and you know the maximum number of elements you want to 
store beforehand.

> 
>  
> 
> The above is only true with what's currently in trunk.  With Collections-ul.867, there is still the case for
> 
>      Dictionary new
> 
> vs
> 
>      Dictionary new: 3
> 
> I hope I'm not missing something again, but because of that I think we should revert your change to HashedCollection class>>#sizeFor:, which is what this new Collections-cmm.870 with uuid c4bf7594-c44e-4d02-9956-2b727d2eb75b does (argh, forgot to up the version #, oh well).

It feels like you're trying to use the "optimization" in #sizeFor: to your 
needs. But you should know that the "optimization" is only there, because 
for small numbers the formula [elements + 1 * 4 // 3] is not a good enough 
approximation of [(elements * 4 / 3) ceiling]. Actually, that formula is 
simply wrong. The correct formula is [elements * 4 + 2 // 3]. I'll push a 
new version with that formula.
But before I do, can you give me the exact cases you're tring to optimize 
for?


Levente

> 
>  Best,
>   Chris
> 
>


More information about the Squeak-dev mailing list