I entered Mantis #2910 with an enhancement that greatly improves
performance of explicit deletion from a WeakKeyDictionary. This is
the bottleneck for e.g. a large WeakRegistry with objects being
added and removed frequently. It does *not* address finalization
performance for the reason explained by Andreas below.

If your application is able to explicitly remove objects most of
the time, as opposed to letting the finalization process take
care of it, you may find that WeakKeyDictionarySpeedup-dtl.cs
helps quite a bit.

Please do not use this on a critical image such as a Seaside
server until some qualified person (aka Andreas) says it's OK.

Dave

On Fri, Feb 10, 2006 at 09:54:54PM -0500, Andreas Raab wrote:
> Hi William -
> 
> William Harford wrote:
> > I am interested to know why WeakArray finalization eats up the CPU when 
> > standard gc does not. The only gc methods I have implemented have been 
> > standard reference counting ones so I know little of the details of 
> > other garbage collectors.
> 
> The main issue is that the garbage collector does not provide sufficient 
> information about which element of what array has been finalized to the 
> image. All the garbage collector does is to signal an event that such a 
> finalization *has* occurred (but not where). Therefore, if you want to 
> react to it you'll have to scan the elements of "your" weak array and 
> the amount of time spent in that process depends both on the number of 
> objects finalized as well as the number of slots scanned.
> 
> > My second question is.....
> > Is there a simple way to implement a WeakArray (WeakValueDictionary) 
> > that handles larger value set better. Maybe a WeakValueDictionary that 
> > only ever looks at 1000 elements at a time for finalization and would 
> > run less often.
> 
> There is no "simple" way for a particular meaning of "simple" - the 
> current mechanism (which I wrote years and years back) was by far the 
> simplest thing that could possibly work and it has served its intended 
> purposes (mainly avoiding dangling resource handles like files or 
> sockets) very well. It was never intended to scale up to thousands of 
> objects. Any other mechanism will necessarily be more complex than the 
> current mechanism.
> 
> Cheers,
>    - Andreas