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).<p>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 <a href="http://golang.org/src/pkg/runtime/hashmap.c" rel="nofollow">http://golang.org/src/pkg/runtime/hashmap.c</a> to see what good structure design and experimentation gets you.<p>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?