[DrJosiah]

This is probably a bit off topic, but I notice that they implemented their own hashmap with pluggable hash functions. Awesome in theory (and practice), though I notice that the performance of their custom hash table is poorer than Go's built-in hash map (Go's hashmap takes 1/2, 3/4, and 9/10th the time of their hashmap for small, medium, and large keys, respectively - though this could be related to the updated aes hash in Go, and that my processor supports it).

While looking through the implementations, the Gnatsd hashmap implementation is a simple table with buckets, where as the Go hashmap also uses a table with buckets, though each "bucket" has 8 slots by default (and does subsequent chaining). Go's chunking of buckets helps caches work better, reduces random reads, and helps to minimize overhead (fewer pointers if you have fixed-size data). Read the first 83 lines of http://golang.org/src/pkg/runtime/hashmap.c to see what good structure design and experimentation gets you.

Does someone have an example where a 'go test --bench="." -gcflags="-B"' call in the gnatsd/hashmap path actually comes out ahead for the Gnatsd hashmap using a recent Go?

[krobertson]

Derek's hashmap was faster than than Go 1.0's built in hashmap. With Go 1.1 or 1.1.1 (don't remember which one exactly), the standard one did become faster, though Derek had decided to stick with it as is. I can ask him what the reason was... I don't recall right now.

[DrJosiah]

I think I may know why they are sticking with the self-built version: random key selection. The built-in hash map doesn't include a method to discover a random key, but the gnatsd hashmap does.