Re: [PATCH v2 00/10] compat/zlib: allow use of zlib-ng as backend

> Hi,
>
> I have recently started to play around with zlib-ng a bit, which is a
> hard fork of the zlib library. It describes itself as zlib replacement
> with optimizations for "next generation" systems. As such, it contains
> several implementations of central algorithms using for example SSE2,
> AVX2 and other vectorized CPU intrinsics that supposedly speed up in-
> and deflating data.
>
> And indeed, compiling Git against zlib-ng leads to a significant speedup
> when reading objects. The following benchmark uses git-cat-file(1) with
> `--batch --batch-all-objects` in the Git repository:
>
>     Benchmark 1: zlib
>       Time (mean ± σ):     52.085 s ±  0.141 s    [User: 51.500 s, System: 0.456 s]
>       Range (min … max):   52.004 s … 52.335 s    5 runs
>
>     Benchmark 2: zlib-ng
>       Time (mean ± σ):     40.324 s ±  0.134 s    [User: 39.731 s, System: 0.490 s]
>       Range (min … max):   40.135 s … 40.484 s    5 runs
>
>     Summary
>       zlib-ng ran
>         1.29 ± 0.01 times faster than zlib
>
> So we're looking at a ~25% speedup compared to zlib. This is of course
> an extreme example, as it makes us read through all objects in the
> repository. But regardless, it should be possible to see some sort of
> speedup in most commands that end up accessing the object database.
>
> This patch series refactors how we wire up zlib in our project by
> introducing a new "compat/zlib.h" header function. This header is then
> later extended to patch over the differences between zlib and zlib-ng,
> which is mostly just that zlib-ng has a `zng_` prefix for each of its
> symbols. Like this, we can support both libraries directly, and a new
> Meson build options allows users to pick whichever backend they like.
>
> In theory, these changes shouldn't be necessary because zlib-ng provides
> a compatibility layer that make it directly compatible with zlib. But
> most distros don't allow you to install zlib-ng with that layer is it
> would mean that zlib would need to be replaced globally. Instead, they
> typically only provide a version of zlib-ng that only has the `zng_`
> prefixed symbols.
>
> Given the observed speedup I do think that this is a worthwhile change
> so that users (or especially hosting providers) can easily switch to
> zlib-ng without impacting the rest of their system.
>
> Changes in v2:
>   - Wire up zlib-ng in our Makefile.
>   - Exercise zlib-ng via CI by adapting our "linux-musl" job to use
>     Meson and installing zlib-ng.
>   - Link to v1: https://lore.kernel.org/r/20250110-b4-pks-compat-drop-uncompress2-v1-0-965d0022a74d@pks.im
>