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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed May 6 22:13:04 UTC 2009


Created http://bugs.squeak.org/view.php?id=7350

2009/5/6 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
> Ah, I forgot to accept one change!
> It's even better if we decrease the tally when recycling a nil slot in
> #fixCollisionsFrom:
>
> Nicolas
>
> 2009/5/6 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>> Though I have tried to attack it with some tricky combinations, I did
>> not found a problem with current implementation.
>> It was funny to see how nil is handled as any other object in WeakSet
>> fixCollisionsFrom: (scanFor: nil works).
>>
>> However, it's a pity not to recycle all those nils until next grow!
>> Here comes a little trial for recycling reclaimed nil slots in Pharo
>> (seems compatible with 3.10.2).
>> No guarantee... Note there is no WeakSet tests in Pharo nor 3.10.2 currently :(
>>
>> Nicolas
>>
>> 2009/5/6 Andreas Raab <andreas.raab at gmx.de>:
>>> Nicolas Cellier wrote:
>>>>
>>>> Take this example:
>>>
>>> Ah, good point. (it works fine with o1 = 'g' and o2 = o3 = o4 = 'd'). The
>>> thing is that the test in WeakSet>>add: was misleading - it tests for nil
>>> where scanFor: searches only for flag.
>>>
>>> Cheers,
>>>  - Andreas
>>>
>>>> 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