It is trivial to generate a mostly-randomized bijective mapping of small integers to small integers with an xor and a little byte swapping, which is what the author does with a built-in AES instruction.
The OP's point is that this isn't a particularly interesting problem. The interesting problem is generating efficient bijective mappings of large integers to very small integers.
I wasn't attempting to argue the OP's point, merely answering the question posed: "what [is the] value [of randomizing your integer keys] in cases where you know you don't have collisions."
Re:Fast Perfect Hashing
by munificent on Thursday February 14, 2019 @12:06AM
(#19159753)
Thanks, that's an interesting one I'm not familiar with.
If you're going to be doing writes of your data in order of an integer sequence number, and you're writing to a multi-node storage system that partitions/shards by primary-key range, then you're going to get worst-case performance if you use your integer sequence numbers directly as the primary keys, since you're queuing all your writes onto one shard.
Instead, you want to permute your integer sequence numbers so that successive integers become evenly spread across the range partitions. This (along with some write duplication and verify-on-read) is the foundation of Dynamo-based "scale-free" storage systems (DynamoDB+S3, Riak+CS, etc.)