>In my test zlib-ng is about 40% faster. I did some testing with zlib-ng and createrepo-c a few months ago [0], and I also found that the compression portion of the workload was about 40% faster. So this matches my experience, too. (BTW, if that github comment [0] sounds negative, it isn't meant to, it's just that zlib ended up not being the primary culprit of the performance issue I was investigating at the time, so I was not as immediately interested in replacing it.) I support this proposal. A tricky detail is that one of the big upsides of zlib-ng is that it has a lot of optimized codepaths for ARM, POWER, Z, RISC-V, AVX-256, AVX-512 and so forth which madler/zlib does not have. And that's fantastic, but I expect it could make the testing process a bit more painful. Since each of the arch-specific acceleration codepaths is behind a separate build flag [1] though, (I assume) we could easily do a more conservative rollout with most arch-specific optimizations disabled at first, and then enabled gradually over time. [0] https://github.com/rpm-software-management/createrepo_c/pull/335#issuecomment-1381362220 [1] https://github.com/zlib-ng/zlib-ng#advanced-build-options _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
