P.S.  The builtin hash table is pathetically crufty, buggy, etc. and could use a rewrite, but even if/when this happens, I still think a separate sealed container implementation would be a Good Thing.<br><br><div class="gmail_quote">
On Fri, Oct 22, 2010 at 10:22 AM, David Simcha <span dir="ltr">&lt;<a href="mailto:dsimcha@gmail.com">dsimcha@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The main problem with replacing the builtin hash table is that the builtin isn&#39;t sealed (and as far as I can tell isn&#39;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.<div>
<div></div><div class="h5"><br>
<br><div class="gmail_quote">On Fri, Oct 22, 2010 at 10:06 AM, Andrei Alexandrescu <span dir="ltr">&lt;<a href="mailto:andrei@erdani.com" target="_blank">andrei@erdani.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

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?<br>
<br>
We&#39;d need a battery of tests for such, and I see you already got one from PyDict. Great!<br>
<br>
<br>
Andrei<div><div></div><div><br>
<br>
On 10/22/10 8:59 CDT, David Simcha wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><div>
I&#39;ve come to the realization that one of the most annoying library level<br>
problems in D2 is lack of a good hash table implementation for large<br>
tables. The builtin AAs aren&#39;t bad for small to medium sized tables, but<br>
are absolutely terrible for large tables due to the way they manage<br>
memory. Is anyone already working on a sealed container implementation<br>
of hash tables? If not, would others be interested in my RandAA<br>
(<a href="http://dsource.org/projects/aa" target="_blank">http://dsource.org/projects/aa</a>) after some cleanup, etc.? I believe<br>
that this design is extremely well suited to the sealed container<br>
paradigm, and it interacts much better with the GC than the builtin<br>
impl. when dealing with large arrays.<br></div></div>
_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</blockquote>
_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</blockquote></div><br>
</div></div></blockquote></div><br>