You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current performance for Get is between 2 and 7 times slower than native implementation for maps (depending on map size). There are many possible reasons, including the performance of the hashing mechanism.
The current code uses the built-in FNV32a hash methods, as supplied in the hash package. Using the benchmark tools, we can see that...
for i := 0; i < max; i++ {
hasher := fnv.New32a()
binary.Write(hasher, binary.LittleEndian, uint32(i))
hash32 = hasher.Sum32()
}
...takes about 0.02ns / op, where max is 500,000.
Although it seems that there is little to gain here, we might find some slightly better performance by using a custom hashing mechanism.
The text was updated successfully, but these errors were encountered:
On further investigation, after fixing the benchmarking and performing some profiling, it looks like the hashing method may be more at fault than initially presumed. When using the default hash function (FNV32a), the hash function consumed roughly 30% of CPU time.
Current performance for
Get
is between 2 and 7 times slower than native implementation for maps (depending on map size). There are many possible reasons, including the performance of the hashing mechanism.The current code uses the built-in FNV32a hash methods, as supplied in the
hash
package. Using the benchmark tools, we can see that......takes about 0.02ns / op, where max is 500,000.
Although it seems that there is little to gain here, we might find some slightly better performance by using a custom hashing mechanism.
The text was updated successfully, but these errors were encountered: