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