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?

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