By the way, I think that if someone or a group of people would step  
in to fix this problem,
the foundation would really like to support this initiative with some  
money.
Else I do not understand what is our role. So we could be a  
consortium and create a money pot
for fixing this problem.

Stef

On 11 févr. 06, at 10:53, Lukas Renggli wrote:

>> 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.
>
> This is a pity, since Seaside uses WeakArrays to cache session state.
> We had some applications that started to spend a lot (all) of the CPU
> time within the weak-finalizer process. The workaround was to disable
> the use of WeakArrays, with the drawback that memory was released much
> later and the application required much more memory.
>
> For frameworks like Seaside it is essential to have a performant
> implementation of WeakArrays up to an unlimited size. Also
> Dictionaries should have a much better performance, i.e. access-time
> should be O(1) as its name suggests and not O(n) for more than a few
> thousand elements.
>
> My question: How can we improve the current implementation, that
> worked well for years, but that obviously doesn't scale well enough
> anymore? It should be certainly a goal for Squeak 4 to have performant
> WeakArrays and Dictionaries of arbitrary size.
>
> Lukas
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
>
>