// the find
lemire/constmap
A fast, compact, immutable map from strings to uint64 values in Go.
A Go implementation of the binary fuse filter that stores a fixed set of string-to-uint64 pairs at about 9 bytes per key. A lookup is one XXH64 hash, three array reads and two XORs. It suits services that build a static table at startup, such as symbol tables, routing or config lookups, and dictionaries, and then only read from it. It is not a general-purpose map.
The lookup path is about as small as a static map gets: one hash, three loads, two XORs, and no branch on the value. The scaling table shows where the win comes from. At 10,000 keys the gap to Go's map is modest (9.4 ns against 14.8 ns), but at 10 million keys it is about 2x (34.8 ns against 70.1 ns) at 9 bytes per key against 37, so the compactness is doing real work at scale. The benchmark notes are unusually candid: they say a small query sample flatters every implementation, that random query order is needed to exercise the map at all, and that key allocation adds about 11 ns per lookup that belongs to the caller rather than the structure. Serialization is careful too. Writes go out in 64 KiB chunks, the arrays are 8-byte aligned so a reader can alias them, and checked-in fixtures from the Rust and C implementations are tested byte for byte.
ConstMap returns an undefined value for keys it was never given, so any caller that needs membership has to pay for VerifiedConstMap, which doubles the footprint to about 18 bytes per key. The paired variant adds a further trade-off: it is faster for present keys and slower for absent ones, so choosing between the two means knowing your hit rate in advance. The README gives no construction timings, only that construction is slower, and it does not explain what happens at tens of millions of keys. The surface area is large for a small library: three map types, three file formats with different magic bytes, hand-written assembly for amd64 and arm64 with a purego fallback, and an interop corpus that has to stay in sync with two other repos. Each piece is tested, but each is a maintenance commitment, and the history already shows one break. Files from fastconstmap 0.9 used XXH3 and cannot be read here at all. The published numbers also come from the author's two machines.