[squeak-dev] Re: How weak finalization affects the performance

Igor Stasenko siguctua at gmail.com
Tue Oct 26 11:02:25 UTC 2010


2010/10/26 Levente Uzonyi <leves at elte.hu>:
> On Tue, 26 Oct 2010, Igor Stasenko wrote:
>
>> On 26 October 2010 11:49, Andreas Raab <andreas.raab at gmx.de> wrote:
>>>
>>> Hi Igor -
>>>
>>> I'm having a hard time understanding how adding a delay would improve
>>> performance. In my code, adding delays generally does the opposite :-)
>>> Can
>>> you explain *why* you see a performance improvement? The work done for
>>> each
>>> finalized object doesn't differ, does it? So how come you see an
>>> improvement?
>>>
>>
>> Finalization is triggered at each GC cycle. Putting 5 sec delay makes
>> a finalization process to
>> do weak containers scavenging not often than each 5 seconds,
>> instead after each GC.
>>
>> The amount of work to do finalization is same, but you forgetting the cost
>> of scanning weak dicts to find the objects to be finalized.
>
> This is exactly what your new WeakRegistry implementation avoids, isn't it?
>

Yes.

>>
>> The code above actually illustrating this overhead:
>>
>> | dict b |
>> dict := WeakKeyDictionary new addAll: (( 1 to: 1000 ) collect: [:i |
>> i->i] ); yourself.
>> WeakArray addWeakDependent: dict.
>>
>> Here, at each GC cycle, a 'dict finalizeValues' will be sent,
>> which leads to looping over 1000 entries.
>> Add dict with 10000 entries, and you will loop over 10000 after each GC.
>
> You should never register WeakKeyDictionaries to the finalization process.
> They are not thread safe.
>
Yeah.. still there are some code, which used it.

And still WeakArray provides a mechanism to add weak dependents,
so, potentially you could add anything there.  :)

> Since the next VMs will support your new finalization scheme, I see no
> benefit from the delay.
>

Yes. But because Chris have no official VMs with new finalization, he
using this trick to reduce CPU hog in finalization process.

>
> Levente
>
>>
>>
>>
>>> Cheers,
>>>  - Andreas
>>>
>>> On 10/26/2010 12:25 AM, Igor Stasenko wrote:
>>>>
>>>> Here the idea, which came to Chris,
>>>> put a delay into #finalizationProcess loop:
>>>>
>>>> finalizationProcess
>>>>        [true] whileTrue:
>>>>                [ WeakFinalizationList initTestPair.
>>>>                FinalizationSemaphore wait.
>>>>                FinalizationLock critical:
>>>>                        [
>>>>                        WeakFinalizationList checkTestPair.
>>>>                        FinalizationDependents do:
>>>>                                [:weakDependent |
>>>>                                weakDependent ifNotNil:
>>>>                                        [weakDependent finalizeValues]]]
>>>>                        ifError:
>>>>                        [:msg :rcvr | rcvr error: msg].
>>>>                5 seconds asDelay wait.
>>>>                ].
>>>>
>>>>
>>>> And here a simple benchmark, which triggers GC often:
>>>>
>>>> [ Array new: 100 ] bench
>>>>
>>>> without delay:
>>>>
>>>> '2,450,000 per second.'
>>>> '2,490,000 per second.'
>>>> '2,490,000 per second.'
>>>> '2,480,000 per second.'
>>>> '2,530,000 per second.'
>>>>
>>>> with delay:
>>>>
>>>> '2,670,000 per second.'
>>>> '2,680,000 per second.'
>>>> '2,690,000 per second.'
>>>> '2,730,000 per second.'
>>>>
>>>> roughly about ~8% faster :)
>>>>
>>>> But now lets put something big into weak array:
>>>>
>>>> | dict b |
>>>> dict := WeakKeyDictionary new addAll: (( 1 to: 1000 ) collect: [:i |
>>>> i->i] ); yourself.
>>>> WeakArray addWeakDependent: dict.
>>>> b := [ Array new: 100 ] bench.
>>>> WeakArray removeWeakDependent: dict.
>>>> b
>>>>
>>>> without delay:
>>>>
>>>> '1,840,000 per second.'
>>>> '2,060,000 per second.'
>>>> '2,130,000 per second.'
>>>>
>>>> with delay:
>>>>
>>>> '3,030,000 per second.'
>>>> '2,880,000 per second.'
>>>> '2,890,000 per second.'
>>>>
>>>> Do not forget to do:
>>>> WeakArray restartFinalizationProcess
>>>>
>>>> when you changing the #finalizationProcess method,
>>>> otherwise you won't see real numbers.
>>>>
>>>> So, i like the idea of putting delay there.
>>>> Finalization is eventual, and there is no hard guarantees that it will
>>>> happen in micro-second just after some object become garbage.
>>>> So, be it 5 seconds or 1000 seconds not really matters.
>>>> What is matters that with delay we win much more, by avoiding wasting
>>>> time in finalization process too often.
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list