On Tue, Mar 20, 2012 at 10:47 PM, H. S. Teoh <span dir="ltr"><<a href="mailto:hsteoh@quickfur.ath.cx">hsteoh@quickfur.ath.cx</a>></span> wrote:<div><br></div><div>[snip]</div><div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I would say the main benefit is having it implemented in the library,<br>
because that allows the implementation have direct access to key/value<br>
types. I didn't implement any clever new hashing algorithm at all, I<br>
just mainly followed the implementation in aaA.d. But having direct<br>
access to key/value types is a *huge* win.<br>
<br>
For example, it lets you accept keys/values that are not strictly the<br>
AA's key/value type, but can be implicitly converted to them. It lets<br>
you return keys and values without needing the ugly typeinfo and void*<br>
casts that are necessary in aaA.d.  This in turn lets you mark many AA<br>
methods as pure, and almost all as @safe or @trusted. It lets you<br>
cleanly interoperate with types that define opAssign (currently aaA.d<br>
does a blind binary copy of data from key/value pointers, which leads to<br>
potential bugs when the data has subobjects.)<br>
<br></blockquote><div><br></div><div>It's probably far too early to think about this with all the other important issues you're addressing but have you given much thought to improving the hashing function?  I haven't hit any issues with the speed of the current hasher but better performance is always welcome. MurmurHash seems to be all the rage these days with a lot of languages and systems adopting it <<a href="http://en.wikipedia.org/wiki/MurmurHash">http://en.wikipedia.org/wiki/MurmurHash</a>> (it compiles down to ~52 instructions on x86). It'd be interesting to see benchmarks with it. I'm not sure where the current hashing function lives to see what it's like.</div>
<div><br></div><div>Regards,</div><div>Brad Anderson</div></div></div>