Sergey "Shnatsel" Davidoff

Rust just doesn't allow creating a `&[u8]` over a memory map, which is required for the `Read` trait. You _can_ take a raw pointer to the memory map and [`ptr::read_volatile`](https://doc.rust-lang.org/stable/std/ptr/fn.read_volatile.html)...

When reading from a file, you'll need to open multiple `File` handles (backed by a file decriptor) and wrap each one in its own `BufReader`. For reading from an in-memory...

It would be interesting to have benchmarks on x86 as well as ARM. I've tried running the benchmarks from #181 on a 16-core Ampere Altra machine from Google Cloud, and...

We should also back that up with benchmarks. I doubt LTO is going to be much of a gain. `-C codegen-units=1` is also worth a shot. And if `-Ctarget-cpu=native` does...

The latest version of `half` crate now uses the f16 conversion intrinsics on stable Rust, so reading to f16 will be a lot faster on `half` v2.3.1 and later.

If you omit `--locked`, a newer `crossbeam-channel` will be selected without the warning. I don't think there's anything that can be easily done about `atty` without patching `clap`.

You can find more details about the way unitialized memory is treated by C and Rust here: https://www.ralfj.de/blog/2019/07/14/uninit.html `flate2` itself does not read from the backing slice, but the compiler...

If you are creating a vector from scratch, using `vec![0; capacity]` is faster than `vec.resize(capacity, 0)` because it requests already-zeroed memory from the OS.

I don't see why any of those solutions would be better than `vec.resize(capacity, 0)`. We could avoid re-initializing the same part over and over by keeping track what part of...

The approach of writing to the spare capacity without zeroing it first sounds good, provided that the C library wrappers are adjusted to write to a `&mut [MaybeUninit]`.