Benchmark comparison quite slow?

[cikasfm]

Hi!

During a cache evaluation process for our product openfga/openfga to try & replace now seeming to be legacy ccache I wanted to check go-freelru by elastic, which seemed to be quite competitive from the papers.

However, after I've added a perf benchmark test for go-freelru on maypok86/benchmarks repo ( see PR 38 ) I've noticed that basic test shows that go-freelru is consistently one of the slowest of the bunch ( ~200ns/op vs 5-10ns/op by some TinyLFU competitors )

Am I doing some incorrect configuration?

[rockdaboot]

Hi, thanks for reaching out.

200ns sounds like an extremely bad value that doesn't show up in the go-freelru benchmarks.

Without looking into the benchmark suite, there may be several reasons for slowness:

1. lock contention: SyncedLRU behaves badly in highly parallel workloads. Use ShardedLRU instead.
   Numbers from go-freelru benchmark:

BenchmarkParallelSyncedGet-20                            8020772               138.3 ns/op             0 B/op          0 allocs/op
BenchmarkParallelShardedGet-20                          159503331                7.294 ns/op           0 B/op          0 allocs/op

2. collisions: the hash function doesn't fit and leads to a degenerated hash table

3. You may want to test xxh3 for hashing strings. Numbers from the go-freelru benchmark:

BenchmarkHashString_FNV1A-20                            58426250                19.42 ns/op
BenchmarkHashString_AESENC-20                           487277858                2.410 ns/op
BenchmarkHashString_XXHASH-20                           185790025                6.490 ns/op
BenchmarkHashString_XXH3HASH-20                         361552785                3.264 ns/op

(The AESENC is what Go maps use internally, but is hardly portable.)