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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected] <mailto:[email protected]>
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
