Double index map read/write benchmarks, better copy available for [16]byte keys?

I've got a project I'm working on with two uint64 ids, typeID and objectID, and I'm planning to hold lite metadata in memory. This got me thinking about map access speeds and I found a double map was fastest (code: https://github.com/borgehl/arbitrary-playgrounds/blob/main/go/maps/benchmarking/main.go).

// time in seconds, 3000 x 3000 size, read/write all mapmap took 0.782382 to make mapmap took 0.318538 to read mapStr took 4.336261 to make mapStr took 2.557962 to read mapStr2 took 4.529796 to make mapStr2 took 2.648919 to read mapBytes took 2.155650 to make mapBytes took 1.455430 to read

There's lots of optimization to make on the use case (typeID << fileID for one), I was surprised the keys of [16]byte weren't more performant. I expect this has to do with creating the key by copying over the indexes into the key. Is there a better way to place the bytes from uint64 into [16]byte?

Conventional wisdom says a single map index should be more performant, but perhaps this is one of those edge cases (based on the keys being uints) that it's not the case?

Compared to everything else, this is likely not a necessary optimization but I got curious.

submitted by /u/Heavy_Manufacturer_6
[link] [comments]