244 | @@ -245,6 +245,14 @@ static inline uint32_t RollingBloomHash(unsigned int nHashNum, uint32_t nTweak,
245 | return MurmurHash3(nHashNum * 0xFBA4C795 + nTweak, vDataToHash);
246 | }
247 |
248 | +
249 | +// A replacement for x % n. This assumes that x and n are 32bit integers, and x is a uniformly random distributed 32bit value
250 | +// which should be the case for a good hash.
251 | +// See https://lemire.me/blog/2016/06/27/a-fast-alternative-to-the-modulo-reduction/
252 | +static inline uint32_t FastMod(uint32_t x, size_t n) {
nit: Could replace inline with constexpr
Would that make a difference in the generated code?
That's very unlikely - the sort of optimizations that apply to constexpr things also apply to things which the compiler can infer being constant expressions (which is obvious here).
The advantage to using constexpr is making sure those optimizations aren't made impossible for some reason.
Agreed it's unlikely. My inclination is to minimize surface area and maximally restrain the code to reduce the space of errors that might occur. It's not always meaningful, but it can be a helpful precaution and can pay incidental dividends, e.g. by surfacing changes to the use of variables over time that were not intended. But yeah, it's a nit rather than an objection.
