On Thu, Jun 27, 2024 at 7:16 AM Hou Tao <houtao@xxxxxxxxxxxxxxx> wrote: > > > The first version of qp-trie had already supported to use arbitrary > bytes as key [1]. The lookup performance comparison between qp-trie and ahh. great. 2 years is a long time :) > hash-table varies according to the benchmark result in the early > patch-set [1]. For normal strings (e.g., strings in BTF or kallsyms), > hash-table performance better. I will try whether or not it is possible > to work out a hack version for both hash-table and qp-trie to compare > the lookup performance first. I think the real life use of qp-trie will demonstrate bigger wins, since in your example you just sized up hash key_size as 256 (iirc), but for tools like bpftrace there is no good number. Users that would want to use file path as a key would ask for 4096, but that's massive overkill. The hashing of 4096 bytes is going to be more expensive than a qp-trie walk. So from usability pov qp-trie is auto-sized while the current hash map is pretty difficult to use with strings. dynptrs in a key proposal might help hash map quite a bit. At the end there will be cases where this new hash map with dynptr support will work better than qp-trie and the other way around.
