A Golang lock-free thread-safe HashMap optimized for fastest read access.
It is not a general-use HashMap and currently has slow write performance for write heavy uses.
Example uint8 key map uses:
m := New[uint8, int]()
m.Set(1, 123)
value, ok := m.Get(1)
Example string key map uses:
m := New[string, int]()
m.Set("amount", 123)
value, ok := m.Get("amount")
Using the map to count URL requests:
m := New[string, *int64]()
var i int64
counter, _ := m.GetOrInsert("api/123", &i)
atomic.AddInt64(counter, 1) // increase counter
...
count := atomic.LoadInt64(counter) // read counter
Reading from the hash map for numeric key types in a thread-safe way is faster than reading from a standard Golang map
in an unsafe way and three times faster than Golang's sync.Map:
ReadXsyncMapUint-8                924.5n ± ∞ ¹
ReadHashMapUint-8                 1.072µ ± ∞ ¹
ReadHaxMapUint-8                  1.296µ ± ∞ ¹
ReadGoMapUintUnsafe-8             1.318µ ± ∞ ¹
ReadGoSyncMapUint-8               3.389µ ± ∞ ¹
ReadSkipMapUint-8                 4.820µ ± ∞ ¹
ReadGoMapUintMutex-8              32.62µ ± ∞ ¹
Reading from the map while writes are happening:
ReadHashMapWithWritesUint-8       1.235µ ± ∞ ¹
ReadHaxMapWithWritesUint-8        1.433µ ± ∞ ¹
ReadGoSyncMapWithWritesUint-8     4.503µ ± ∞ ¹
Write performance without any concurrent reads:
WriteGoMapMutexUint-8             21.72µ ± ∞ ¹
WriteHashMapUint-8                27.99µ ± ∞ ¹
WriteGoSyncMapUint-8              78.43µ ± ∞ ¹
The benchmarks were run with Golang 1.24.4 on Linux and a Ryzen 9 5900X CPU using make benchmark-perflock.
- 
Technical design decisions have been made based on benchmarks that are stored in an external repository: go-benchmark
 - 
The library uses a sorted linked list and a slice as an index into that list.
 - 
The Get() function contains helper functions that have been inlined manually until the Golang compiler will inline them automatically.
 - 
It optimizes the slice access by circumventing the Golang size check when reading from the slice. Once a slice is allocated, the size of it does not change. The library limits the index into the slice, therefore the Golang size check is obsolete. When the slice reaches a defined fill rate, a bigger slice is allocated and all keys are recalculated and transferred into the new slice.
 - 
For hashing, specialized xxhash implementations are used that match the size of the key type where available