zlib-ng is a high-performance zlib implementation, to handle DEFLATE/gzip compression and decompression.
TLDR: if you are using flate2, and want higher performance, change your flate2 dependency to:
flate2 = { version = "1.0.24", default-features = false, features = ["zlib-ng"] }
Previously, I added support for zlib-ng in flate2 via zlib-ng's "zlib-compat" mechanism, which builds a zlib-compatible ABI. However, this support only works if nothing in your dependencies (whether Rust or C) uses stock zlib, or uses a system library that links to zlib. Otherwise, you'll get symbol conflicts at link time or runtime.
I've now added support in flate2 to use zlib-ng via its native API (which prefixes all symbols with zng_), and I've also released a new crate libz-ng-sys which provides that native API. libz-ng-sys provides an almost identical interface to libz-sys (consuming the zng_ C API but providing a Rust API without those prefixes), so that any crates using libz-sys directly (as flate2 did) can easily switch to libz-ng-sys or support both.
If you're currently using flate2, I would recommend switching to the zlib-ng feature. (You may optionally want to provide options via feature flags.)
Additional note for maintainers of C library bindings
If you are linking a C library that itself requires the zlib API and doesn't natively support zlib-ng, and you're using `libz-sys` to link to zlib, you may still wish to support the `zlib-ng-compat` option so that the C library can use `zlib-ng` as well. You may also want to add native support for zlib-ng to the C library, and then use `libz-ng-sys` to link to zlib-ng natively.(Posted to internals because these are official Rust crates, but I've also cross-posted this to users.)