On Tue, Mar 20, 2012 at 10:47 PM, H. S. Teoh <hst...@quickfur.ath.cx> wrote:
[snip] I would say the main benefit is having it implemented in the library, > because that allows the implementation have direct access to key/value > types. I didn't implement any clever new hashing algorithm at all, I > just mainly followed the implementation in aaA.d. But having direct > access to key/value types is a *huge* win. > > For example, it lets you accept keys/values that are not strictly the > AA's key/value type, but can be implicitly converted to them. It lets > you return keys and values without needing the ugly typeinfo and void* > casts that are necessary in aaA.d. This in turn lets you mark many AA > methods as pure, and almost all as @safe or @trusted. It lets you > cleanly interoperate with types that define opAssign (currently aaA.d > does a blind binary copy of data from key/value pointers, which leads to > potential bugs when the data has subobjects.) > > 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 <http://en.wikipedia.org/wiki/MurmurHash> (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. Regards, Brad Anderson
