On Tue, 26 Oct 2010, Igor Stasenko wrote:

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

In Squeak?

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

Yes, but it's your responsibility to add appropriate objects.

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

According to the current schedule, the new VMs will be released in 
december.


Levente

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