[Pharo-project] How weak finalization affects the performance

Oct. 26, 2010

      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.