Martin KaFai Lau wrote: > On Tue, Jun 21, 2022 at 12:17:54PM -0700, John Fastabend wrote: > > > Hashmap Control > > > =============== > > > num keys: 10 > > > hashmap (control) sequential get: hits throughput: 20.900 ± 0.334 M ops/s, hits latency: 47.847 ns/op, important_hits throughput: 20.900 ± 0.334 M ops/s > > > > > > num keys: 1000 > > > hashmap (control) sequential get: hits throughput: 13.758 ± 0.219 M ops/s, hits latency: 72.683 ns/op, important_hits throughput: 13.758 ± 0.219 M ops/s > > > > > > num keys: 10000 > > > hashmap (control) sequential get: hits throughput: 6.995 ± 0.034 M ops/s, hits latency: 142.959 ns/op, important_hits throughput: 6.995 ± 0.034 M ops/s > > > > > > num keys: 100000 > > > hashmap (control) sequential get: hits throughput: 4.452 ± 0.371 M ops/s, hits latency: 224.635 ns/op, important_hits throughput: 4.452 ± 0.371 M ops/s > > > > > > num keys: 4194304 > > > hashmap (control) sequential get: hits throughput: 3.043 ± 0.033 M ops/s, hits latency: 328.587 ns/op, important_hits throughput: 3.043 ± 0.033 M ops/s > > > > > > > Why is the hashmap lookup not constant with the number of keys? It looks > > like its prepopulated without collisions so I wouldn't expect any > > extra ops on the lookup side after looking at the code quickly. > It may be due to the cpu-cache misses as the map grows. Maybe but, values are just ints so even 1k * 4B = 4kB should be inside an otherwise unused server class system. Would be more believable (to me at least) if the drop off happened at 100k or more.
