[squeak-dev] Re: Odd performance characteristics of symbol creation

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed May 6 19:38:21 UTC 2009


Take this example:

ws := WeakSet new.
array := WeakSet new instVarAt: (WeakSet allInstVarNames indexOf: 'array').
o1 hash \\ array size + 1 -> 1.
o2 hash \\ array size + 1 -> 2.
o3 hash \\ array size + 1 -> 1.
ws add: o1; add: o2; add: o3.

o1 := o2 := nil.
Smalltalk garbageCollect.
"o1 and o2 are reclaimed."
(array at: 1) -> nil.
(array at: 2) -> nil.

o4 hash \\ array size + 1 -> 1.
ws add o4.
(array at: 1) -> o4.

(ws includes: o3) -> false.

I will try and build a test case. Should be easy with Fractions.

2009/5/6 Andreas Raab <andreas.raab at gmx.de>:
> Nicolas Cellier wrote:
>>
>> Isn't that dangerous if you don't fixCollisionsFrom: index ?
>
> Why would it? All this does is avoiding to update the tally ivar if we're
> replacing a previously reclaimed entry with a new value. And I don't think
> that #fixCollisionsFrom: even looks at tally.
>
> Cheers,
>  - Andreas
>
>> Nicolas
>>
>> 2009/5/6 Andreas Raab <andreas.raab at gmx.de>:
>>>
>>> Adrian Lienhard wrote:
>>>>
>>>> I haven't had time to look into this very closely yet but maybe somebody
>>>> else already knows what is going on. My guess is that the NewSymbols
>>>> weak
>>>> set is repeatedly grown since tally is not decreased if the GC removes a
>>>> weak element.
>>>
>>> That's an excellent guess. Try changing WeakSet to e.g.,
>>>
>>> WeakSet>>atNewIndex: index put: aValue
>>>   "Add newValue at the given index. Don't increment tally
>>>    if current slot is nil since a previous value has been collected"
>>>   (array at: index) ifNil:[^array at: index put: aValue].
>>>   ^super atNewIndex: index put: aValue
>>>
>>> Cheers,
>>>  - Andreas
>>>
>>>
>>>
>>
>>
>
>
>



More information about the Squeak-dev mailing list