On Tue, 5 Oct 2010, Igor Stasenko wrote:
2010/10/4 Levente Uzonyi <le...@elte.hu>:
On Mon, 4 Oct 2010, Igor Stasenko wrote:
On 4 October 2010 22:51, Henrik Sperre Johansen
<henrik.s.johan...@veloxit.no> wrote:
On 04.10.2010 21:47, Igor Stasenko wrote:
On 4 October 2010 22:09, Stéphane Ducasse<stephane.duca...@inria.fr>
wrote:
so let us know in the bug entry what is the conclusion :)
I think someone should verify my benchmarks i.e.
[ self loadsomething ] timeToRun
before and after patch.
And conclusion is better be written by Henrik, because he's having
concerns about speed,
while i don't. :)
I already have:
http://code.google.com/p/pharo/issues/detail?id=1628#c13
emm.. wait.
WeakKeyDict should not delete associations with nil-ed keys
automatically, because otherwise
you won't be able to use it in weak finalization scheme.
There is two distinct use cases of weak-key dicts:
a) for weak finalization
b) for attaching some extra info(value) per object(key), which can be
automatically discarded once object become garbage
so, while in case (b) you can mercilessly kill/reuse associations with
nil keys, once they discovered
in case (a) you should preserve them until there is explicit request
from outside to finalize values.
The need in (a), apparently prohibits from using (b) in most efficient
manner.
So, i think, the solution would be to introduce a specialized weak-key
dicts, which can work much better for (b).
Squeak's implementation works well in both cases.
Trust me, scanning a whole dict to detect nil keys is not what can be
called 'well' :)
My point is, that these two scenarios should use different classes/implementors
each optimized for own case.
Moreover, case (b) comes from the inability to dynamically add extra
slot(s) to object,
which you can easily do in Self or JavaScript, but can't do in smalltalk.
It can be done better, with extra VM features, but without those, it's
pretty close to best possible solution IMHO.
There are already two different classes for a) and b): WeakRegistry
and WeakKeyDictionary (and subclasses).
Levente
Levente
Cheers,
Henry
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
