and this is another reason to use zlib from chrome

https://cs.chromium.org/chromium/src/third_party/zlib/patches/0002-uninitializedcheck.patch

https://chromium-review.googlesource.com/688501

Performance charts of chromium zlib decompression speed for gzip content on ARM and Intel using zlib_bench and snappy dataset (https://github.com/google/snappy/tree/master/testdata).

For original data:
a) ARM: https://docs.google.com/spreadsheets/d/1kLp0UfvCbnAvJUnSQU3b9wMopjqQsfKR0izFMu1Zd0Q/edit#gid=0

b) Intel: https://docs.google.com/spreadsheets/d/15b0-iT0sXB5_d8yN--y48dRhySkeFe3frjWIv7_Vivw/edit#gid=595603569

Deleted: czlib_arm.png 11.1 KB

	czlib_arm.png 11.1 KB View Download

Deleted: czlib_intel.png 26.8 KB

	czlib_intel.png 26.8 KB View Download

Depending on the entropy of the data, speeds for decompressing can be up to 2.1x (ARM) to 2.3x (Intel) for HTML as an example when compared to a vanilla zlib.

+vapier

Mike, any comments?

seems like this idea comes up from time to time for various third party libs that Chromium s bundles. we inevitably drop it after we find the Chromium side focuses only on the things it cares about and not a general purpose distro.

sometimes Chromium lags in versions too, and we don't have the resources to update it in Chromium just so we can get it in CrOS. granted this is less of an issue for zlib due to its slow release schedule, but it has come up before.

plus all the code is checked into src.git and there's no way we support building code out of that since it's way too large. we'd need a gsubtree first before we would even consider it.

how many users of zlib are actually in the CrOS side that'd make us look into this? system code is often not as perf sensitive as the browser. have you talked to the cwp guys to see if zlib shows up anywhere on the system side?

@vapier: sorry for the long delay, I was busy working in other subjects**.

I can't comment on 'cwp guys' (even though I would love to talk to
them to learn about possible hotspots in CrOS side and see if we could
help to improve it).

Addressing one point you mentioned: lagging versions. We are keeping Chrommium's zlib up to date, even backporting fixes from zlib/develop branch, plus applying our own security fixes.

As a result of all this active work, both PDFium (Chrome PDF reader) and Skia had migrated to Chromium's zlib.

To quote Mike Klein@Skia:
"It really is worth re-emphasizing this point. We've found upstream zlib completely unresponsive to both our security and performance patches. I wouldn't recommend running Chromium against a zlib that is not third_party/zlib.", please check: https://chromium-review.googlesource.com/c/chromium/src/+/947464/

I discussed the matter with Chris Dibona and he suggested that we should instead make Chromium's zlib the new standard.

What I don't quite understood is the comment about 'all code checked into src.git'.

It seems like an easy and small checkout (unless I'm not factoring some other detail):
adenilson@chrome-monster:~/temp$ time git clone https://chromium.googlesource.com/chromium/src/third_party/zlib c-zlib
Cloning into 'c-zlib'...
remote: Total 1314 (delta 858), reused 1314 (delta 858)
Receiving objects: 100% (1314/1314), 659.72 KiB | 3.49 MiB/s, done.
Resolving deltas: 100% (858/858), done.

real	0m5.707s
user	0m0.197s
sys	0m0.082s

adenilson@chrome-monster:~/temp$ du -h c-zlib/ --max-depth=0
2.3M	c-zlib/

I'm not really familiar with the specifics of CrOS internals (or if
any of its components are performance bound to zlib), but I recall
that git uses zlib (as also ssh if data compression is enabled).

Let me know if is there any other concern that may be a blocker to
move to Chromium's zlib.

I'm aware that Android is considering porting the optimizations, as that would
 be potentially helpful (i.e. APKs are gzipped compressed and we could make opening them 2x faster).

** Other subjects
a) boosting zlib *compression* in 36% on ARM (https://chromium-review.googlesource.com/c/chromium/src/+/1173262 and https://chromium-review.googlesource.com/c/chromium/src/+/1136940/)

b) improving layout performance in 17% to 22% (https://bugs.chromium.org/p/chromium/issues/detail?id=902782, https://bugs.chromium.org/p/chromium/issues/detail?id=907244 and https://bugs.chromium.org/p/chromium/issues/detail?id=735674).

Updated performance data comparing Chromium's zlib (compression/decompression) on ARM/x86 versus Vanilla can be found at:
https://goo.gl/qLVdvh

if zlib is a dedicated repo now and not checked into src.git, that's fine.

it looks like the build tooling has been ripped out and only BUILD.gn is left which doesn't work.  it needs to have standalone build logic.  it also needs to be 100% ABI compliant with the canonical zlib (symbol versions at all), none of which is in BUILD.gn.  those are all hard non-starters.

there are a number of places where zlib is used in CrOS, but i'm having a hard time thinking of any that are performance critical.  git is never shipped on Chromebooks, so that's not interesting.  OpenSSH is shipped, but we never run it directly (and even then, it requires the non-default -C option), so that's not interesting.

Android is a completely standalone environment and wouldn't use the zlib that's in the CrOS rootfs, so they wouldn't have any impact on us, nor us on them.  they can switch independently.

so to reiterate: (i don't think) anyone is debating whether the Chromium's version of zlib is faster than the latest upstream release.  however, we have no data to show that it's used anywhere on CrOS in a way that matters to performance.  if i could write a replacement for `ls` that was a billion times faster, CrOS wouldn't be interested because we never use `ls` and care that it's super fast, only "fast enough".

so can someone research and provide data to show that it's worth the effort for CrOS to switch ?