[phobos] Sealed Hash Tables

[Andrei Alexandrescu]

Then I think that's a good addition to std.container. Before that, we 
should discuss in more depth allocators. This is because some use cases 
will prefer malloc and others will prefer the GC heap.

For example, a class that has a sealed container as member wouldn't want 
the container to hold on to some mallocated chunks until the next GC cycle.


Andrei

On 10/22/10 9:22 CDT, David Simcha wrote:
> The main problem with replacing the builtin hash table is that the
> builtin isn't sealed (and as far as I can tell isn't supposed to be).
> RandAA is intended to be sealed and has no clean way of allowing ref
> access to contents.  This is the tradeoff that allows very efficient
> memory management in the case of large tables.
>
> On Fri, Oct 22, 2010 at 10:06 AM, Andrei Alexandrescu <andrei at erdani.com
> <mailto:andrei at erdani.com>> wrote:
>
>     If your hash table implementation is interface-compatible with the
>     built-in one and does better than it, the logical path to go is to
>     replace the built-in table with yours. Would you be interested in that?
>
>     We'd need a battery of tests for such, and I see you already got one
>     from PyDict. Great!
>
>
>     Andrei
>
>
>     On 10/22/10 8:59 CDT, David Simcha wrote:
>
>         I've come to the realization that one of the most annoying
>         library level
>         problems in D2 is lack of a good hash table implementation for large
>         tables. The builtin AAs aren't bad for small to medium sized
>         tables, but
>         are absolutely terrible for large tables due to the way they manage
>         memory. Is anyone already working on a sealed container
>         implementation
>         of hash tables? If not, would others be interested in my RandAA
>         (http://dsource.org/projects/aa) after some cleanup, etc.? I believe
>         that this design is extremely well suited to the sealed container
>         paradigm, and it interacts much better with the GC than the builtin
>         impl. when dealing with large arrays.
>         _______________________________________________
>         phobos mailing list
>         phobos at puremagic.com <mailto:phobos at puremagic.com>
>         http://lists.puremagic.com/mailman/listinfo/phobos
>
>     _______________________________________________
>     phobos mailing list
>     phobos at puremagic.com <mailto:phobos at puremagic.com>
>     http://lists.puremagic.com/mailman/listinfo/phobos
>
>
>
>
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos