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.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
