Age | Commit message (Collapse) | Author |
|
* runs well on my Arch laptop but fails on our infra :(
For now simply apply this workaround from @ zclkkk.
Change-Id: Ia164112b8f262f6e3f1bf3714fb4f639069a29ce
|
|
This is an Android-specific fork, so we don't care about these
workflows.
|
|
|
|
This tool is very helpful for comparing different implementations of
zlib.
|
|
- Add Soong blueprint
- Add CRC32 fixes
- Add NDK mappings
All changes were based on the Android fork of Chromium zlib.
As reported by simpleperf, a considerable amount of CPU time is spent
decompressing Android binary XML resources when opening and closing
activities in Settings. Because of this, some binary XMLs from
framework-res.apk have been used for zlib_bench testing.
zlib-ng is significantly faster than vanilla zlib and Chromium zlib
(with optimizations enabled) in terms of compression. 64-bit benchmarks
with zlib_bench64 on Android:
Compression:
+------------------------------------------+------+---------------+---------+-------+
| File | zlib | Chromium zlib | zlib-ng | Unit |
+------------------------------------------+------+---------------+---------+-------+
| res/anim/activity_open_enter.xml | 10.4 | 16 | 25.1 | MiB/s |
| res/anim/activity_close_enter.xml | 9.3 | 15.5 | 21.1 | MiB/s |
| res/transition/move.xml | 9.7 | 16.4 | 21.6 | MiB/s |
| res/drawable/stat_sys_battery_charge.xml | 13.3 | 22.4 | 33.2 | MiB/s |
+------------------------------------------+------+---------------+---------+-------+
The gains are less significant for decompression, and Chromium zlib is
generally slighty faster in this case. However, zlib-ng still tends to
be faster than vanilla zlib:
Decompression:
+------------------------------------------+-------+---------------+---------+-------+
| File | zlib | Chromium zlib | zlib-ng | Unit |
+------------------------------------------+-------+---------------+---------+-------+
| res/anim/activity_open_enter.xml | 136.8 | 150.6 | 153.2 | MiB/s |
| res/anim/activity_close_enter.xml | 125.7 | 133.5 | 123 | MiB/s |
| res/transition/move.xml | 120.6 | 129.9 | 124.4 | MiB/s |
| res/drawable/stat_sys_battery_charge.xml | 194.6 | 222.1 | 217.3 | MiB/s |
+------------------------------------------+-------+---------------+---------+-------+
In combination with enabling -O3 for libpng, zlib-ng speeds up
screenshot saving by 16% on redfin (Cortex-A55 + Cortex-A76) as compared
to vanilla zlib.
While Android is likely to be decompressing much more data than it
compresses, zlib-ng's significantly faster compression should be a
worthwhile tradeoff for its deficiencies in decompression speed.
zlib versions used for benchmarks:
Vanilla zlib: [1] (Chromium zlib with optimizations disabled)
Chromium zlib: [2] with all optimizations enabled
zlib-ng: [3] with Android porting changes
All zlib variants were built with -O3, as per commit [4].
[1] https://android.googlesource.com/platform/external/zlib/+/refs/tags/android-11.0.0_r35
[2] https://android.googlesource.com/platform/external/zlib/+/e620e8065d17bab7c9eefe3a03d7f8b80ca450d6
[3] https://github.com/zlib-ng/zlib-ng/commit/9f784908599006e9f09599b85b495bdcda1f25c4
[4] https://android.googlesource.com/platform/external/zlib/+/18e812de
|
|
chunkmemset_neon().
* using memcpy() forbids optimizer to optimize away the temporary variable due to aliasing rules.
|
|
of the test.
Co-authored-by: Vladislav Shchapov <phprus@users.noreply.github.com>
|
|
favor of compilation and link test. #911
|
|
against clang-6 in CI.
|
|
|
|
respectively.
|
|
|
|
|
|
porting doc.
|
|
|
|
Add casts in order to fix the following warnings [1]:
C:\Users\Nathan\Source\zlib-ng\test\deflate_quick_block_open.c(62,69): warning C4244: '=': conversion from '__int64' to
'uint32_t', possible loss of data [C:\Users\Nathan\Source\zlib-ng\deflate_quick_block_open.vcxproj]
C:\Users\Nathan\Source\zlib-ng\test\deflate_quick_block_open.c(73,1): warning C4244: 'initializing': conversion from '_
_int64' to 'uint32_t', possible loss of data [C:\Users\Nathan\Source\zlib-ng\deflate_quick_block_open.vcxproj]
[1] https://github.com/zlib-ng/zlib-ng/pull/880#issuecomment-802432700
|
|
|
|
Co-authored-by: Hans Kristian Rosbach <hk-git@circlestorm.org>
Co-authored-by: concatime <concatime@users.noreply@github.com>
|
|
Co-authored-by: zhangn1985 <zhangn1985@users.noreply.github.com>
|
|
Commit bc5915e2dec7 ("Fixed unsigned integer overflow ASAN error when
hash_head > s->strstart.") removed hash_head != 0 checks in fast,
medium and slow deflate, because it improved performance [1].
Unfortunately, the attached test started failing after that.
Apparently, as the comments suggest, the code implicitly relies on
matches with the beginning of the window being skipped. So restore the
check.
[1] https://github.com/zlib-ng/zlib-ng/pull/772#issuecomment-710760300
|
|
|
|
6 tests use the same pattern: build a binary linked with zlib-ng and
run it. At the moment this requires 5 near-identical lines of CMake
code, leading to proliferation of copy-paste. Introduce a macro to get
rid of it.
|
|
these CI runs take considerably.
|
|
CMake uses `INCLUDEDIR` instead of `INCDIR`.
|
|
|
|
used to use.
|
|
Two words were swapped in a variable name, leading to empty
libdir and includedir variables in the generated .pc files.
|
|
|
|
The attached test fails with "inflate() failed", because the deflate
stream that it produces ends up being corrupted. Bisect points to the
commit e7bb6db09a18 ("Replace hash_bits, hash_size and hash_mask with
defines."), but it's most likely a coincidence.
In any case, the reason is that if we happen to simultaneously exhaust
all the buffers (in, out and bi), we return finish_started without
writing the end of block symbol, which will never happen afterwards.
Fix by adding another check to the tricky condition: if we are in the
middle of a block, return need_more instead of finish_started.
|
|
|
|
DFLTCC probe points are never activated when compiling with CMake. This
is because check_include_file() only sets an internal CMake variable,
but not a C define [1].
Fix as the link suggests - by adding an explicit add_definitions.
[1] https://cmake.org/pipermail/cmake/2015-June/060830.html
|
|
|
|
|
|
The attached test started failing after commit ad89d5131b29 ("Don't
write end of last block when returning finish_started."): either with
"bi_buf not flushed" message in debug builds, or by producing corrupted
output in release builds.
The problem is that we must not return finish_started when bi_buf is
not empty, because the bits there will be lost. Fix by checking that
bi_valid is not 0.
|
|
|
|
|
|
|
|
README.md changes:
- Added a related projects section at the end.
- Added blank line after header where missing.
- Added extra blank line before header to make them easier to spot as plain-text.
- Changed line-length for Contributing section, to make it more readable as plain-text.
|
|
|
|
|
|
|
|
|
|
|
|
Sync cmake dfltcc descriptions with README.
|
|
Describe DFLTCC options more similarly to the others.
|
|
(Getting compiler version is harder than it sounds :-( so skipping that for now.)
|
|
timeout error.
|
|
|
|
|
|
flag check.
|