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