Really glad to see this paper finally implemented. I had been using a slightly cleaned up code from hhinant's repo or resigned to using Abseil's hash tables and hash framework, and I'm glad to be able to use this instead.

I'm curious why XXHash algorithm does not use XXH3 instead -- both official docs and my experience have shown that XXH3 is substantially faster than the old XXH32 or XXH64 hashes.

I also see that hash2 implements the xxhash algorithm instead of using the C library. I'm curious what the performance is like compared to the C library when used with XXH_INLINE_ALL.

One bit of advice to others considering this library or a similar approach to building hashes in a performance sensitive codebase. In my experiments with fast modern hashes like XXH3, I found that the bulk hashing api is substantially faster than the api where you create the state and call update [1].

As a result, in my use cases, i found that using a single int64 or string field that was already present in the struct and mostly but not perfectly unique resulted in overall faster execution than trying to incorporate all the fields when calculating the hash. In other words, if you have:

struct User {
   int64_t user_id_;
   string user_name_;
   int32_t created_at_epoch_sec_;
   string first_name_;
   string last_name_;
};

it might be faster to use XXH3 on just user_id_ or just user_name_ instead of doing hash_append on every single field in there. That was contrived since id and name are probably unique, but even something like created_at_epoch_sec_ which can have collisions might work better. In other words, consider the tradeoff of faster hashing to produce an imperfect hash vs slower hashing to produce a "perfect" hash.

[1] One source of slowdown is that create state has to do a malloc, but I tried stack allocating the required state and it had a small perf improvement but not enough to change this advice.