Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should support alternative implementations of zlib #63

Closed
joshtriplett opened this issue Jul 1, 2020 · 9 comments
Closed

Should support alternative implementations of zlib #63

joshtriplett opened this issue Jul 1, 2020 · 9 comments

Comments

@joshtriplett
Copy link
Member

libz-sys should have a feature to use an alternative zlib implementation, such as zlib-ng. That would reduce the problem such alternative implementations currently have, of potentially ending up with two conflicting versions of zlib in the same binary. (This could still happen if linking to a system library that links to zlib, though.)

@brainstorm
Copy link

Indeed, would you accept repointing of the submodule to this implementation instead?:

https://blog.cloudflare.com/cloudflare-fights-cancer/
https://github.com/cloudflare/zlib

I think this would speed up a few crates that use libz-sys significantly "for free" (see benchmark plots on the blogpost).

@brainstorm
Copy link

For now I'll try to use this crate: https://crates.io/crates/cloudflare-zlib-sys

@joshtriplett
Copy link
Member Author

@brainstorm Not "repointing", no; cloudflare's zlib has portability issues. It also isn't the highest performance; see GitoxideLabs/gitoxide#1 (comment) for some informal benchmarks.

@brainstorm
Copy link

brainstorm commented Aug 16, 2020

Super interesting, thanks for sharing the benchmarks! I'll try to carve some time to give zlib-ng a go (according to 754ca14) ... I hope it's not x86_64-unknown-linux-musl problematic, I've not seen the target in appveyor.yml. Thanks for your reply and insight in any case!

@joshtriplett
Copy link
Member Author

@brainstorm It should work fine on musl. Please give it a try and let me know if it works.

@joshtriplett
Copy link
Member Author

@brainstorm Currently fixing some issues; new version shortly, which I've now confirmed works on musl (and which will test musl in CI).

@joshtriplett
Copy link
Member Author

Done and released in libz-sys 1.1.0.

@brainstorm
Copy link

brainstorm commented Aug 25, 2020

@brainstorm It should work fine on musl. Please give it a try and let me know if it works.

Getting an interesting segfault on our CI correction: just an assert failure about some boundary assumptions made on bgzf.c:461 from htslib so I'll have to look closer at zlib-ng and that assert:

https://github.com/rust-bio/rust-htslib/pull/237/checks?check_run_id=1024717376#step:7:1962

Will investigate on rust-bio/rust-htslib's PR.

@joshtriplett
Copy link
Member Author

@brainstorm Ah, interesting. Yeah, that assert isn't valid with an alternate zlib implementation; compressBound is allowed to return a different value. It's a worst-case bound, not a normal case.

brainstorm added a commit to rust-bio/rust-htslib that referenced this issue Jul 17, 2021
* Switch zlib implementation to zlib-ng, see rust-lang/libz-sys#63 for context

* Bump to release 1.13

* Bump to htslib version 1.13+htscodecs and curl-sys version, build fails

* fix build.rs for htslib changes

* fmt, use recursive submodule checkout on GH Actions

Co-authored-by: Roman Valls Guimera <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants