I mentioned the only real advantage of Crockford Base32 over Hashids was performance. What I did not know at the time was how big an advantage that really is.
A quick review
Hashids (my implementation thereof being harsh) hardens identifiers by shortening and (slightly, pseudo) randomizing them. This makes them a little easier to convey by phone and more difficult to guess via incrementing up or down, although there is nothing cryptographic about the algorithm and it could never stand up to any serious analysis.
I should note that my implementation is not the only Rust implementation of Hashids, but it's the only one that's still maintained. I would also say it's the only one that doesn't suck, but... Well, I guess I just did say that. Whatever.
Crockford Base32 (my implementation thereof being crockford) mostly just makes identifiers telephone game-resistant by eliminating easily-confused digits and shortening numbers. Crockford identifiers can also contain check digits, but my implementation does not allow for these.
My Crockford Base32 implementation is, to my knowledge, the only Rust implementation intended for use specifically with identifiers. The other base32 crate just does base32 encoding of arbitrary data, which I found too painful to use.
The performance numbers
These benchmarks are pretty ugly. The numbers are huge because I'm encoding and decoding a wide swath of numbers in each one. The reason for this is just that performance for the encoding/decoding varies significantly with the length of the number being encoded.
c-v-h [master●] cargo bench Finished release [optimized] target(s) in 0.0 secs Running target/release/deps/c_v_h-1e2012210acf2e44 running 4 tests test decode::crockford ... bench: 1,840,713 ns/iter (+/- 219,993) test decode::harsh ... bench: 96,569,325 ns/iter (+/- 2,649,946) test encode::crockford ... bench: 2,996,443 ns/iter (+/- 401,834) test encode::harsh ... bench: 81,084,603 ns/iter (+/- 5,076,625) test result: ok. 0 passed; 0 failed; 0 ignored; 4 measured; 0 filtered out
(I wish I got syntax highlighting for this stuff. That would be pretty neat, huh? I guess I could just post a screenshot, but most people hate that.)
Honestly, I was about five nines certain that Crockford Base32 would be more efficient than Hashids because of the fact that Hashids requires the copying and shuffling of a big-ass array in order to encode or decode anything, but the margins here blew my mind.
Crockford is 25-50 times faster than harsh.
...My buddy asked me if I thought that would convince anyone to switch to Crockford encoding from Hashids. My initial response was, "Nah." Then, "Well, it will make me switch." But I still dunno about anyone else. I don't see the node.js crowd as being particularly worried about that. :)