No, you can't do the same thing in Rust, because Rust crates and the standard library generally use the global allocator and not any arena you want to use in your code.
The paper does not make that claim. According to the paper the probability of recovering the correct value of a single bit is 96% for a pristine drive and 56% for a used drive, both better than a coin toss. Of course the probability gets worse if one tries to recover more bits (but still better than n coin tosses for n bits).
Nope, pure compile time on a Core i7-10750H with Windows and Rust 1.52.1, antivirus disabled. WSL did not make much of a difference though (29 seconds).
It does not just feel faster, in many cases it is faster.
E.g. compiling Rust code is so much faster that it is not even funny. cargo install -f ripgrep takes 22 seconds on a Mac Book Air with M1, same on a hexacore 2020 Dell XPS 17 with 64GB RAM takes 34 seconds.
Check the benchmarks section (https://github.com/rusticstuff/simdutf8#Benchmarks), second table. simdutf8 is up to 28 % faster on my Comet Lake CPU. However with pure ASCII clang does something magical with simdjson and it beats my implementation by a lot. GCC-compiled simdjson is slower all around except for a few outliers with short byte sequences.
The algorithm is the one from simdjson, the main difference is that it uses an extra step in the beginning to align reads to the SIMD block size.
Make sure to fix the zippers in place. Otherwise it is very easy to still open the bag by just prying open the zippers and closing them again by moving the tied-together zippers.
For critbit trees the entire string _up to_ the critical bit where the string differs from all others already in the datastructure needs to be scanned.
critbit trees degenerate badly if you store strings and their prefixes, e.g. storing a, aa, aaa, ...