touch-packages team mailing list archive
-
touch-packages team
-
Mailing list archive
-
Message #131108
[Bug 1537635] Re: Reduce zlib compression level for massive performance increase
Level 5 isn’t crazy, though it’s still some 70% slower than level 1.
zlib.compressobj(level=1) time=7.6 size=84869397
zlib.compressobj(level=2) time=7.8 size=82465461
zlib.compressobj(level=3) time=8.4 size=79576183
zlib.compressobj(level=4) time=12.2 size=74672475
zlib.compressobj(level=5) time=13.2 size=72642875
zlib.compressobj(level=6) time=15.7 size=69988031
zlib.compressobj(level=7) time=17.9 size=69281853
zlib.compressobj(level=8) time=30.4 size=68666299
zlib.compressobj(level=9) time=59.0 size=68326007
bz2.BZ2Compressor(compresslevel=1) time=30.6 size=61319073
bz2.BZ2Compressor(compresslevel=9) time=40.0 size=54246781
lz4.compress time=2.4 size=108683033
Sizes are after base64 encoding.
(If you’re worried about upload size, why not recompress the report at
upload time, when it’s not going to take the user by surprise?)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1537635
Title:
Reduce zlib compression level for massive performance increase
Status in Apport:
New
Status in apport package in Ubuntu:
Confirmed
Bug description:
When apport takes a core dump of a large application, it uses 100% CPU
for a _long_ time (often 30 seconds or more) to compress the core
dump. The system is virtually unusable during this time, especially if
the application was the window manager and won’t be restarted until
the core dump is complete.
This is a longstanding known problem; it motivated the switch from
bzip2 to zlib level 9 back in apport 0.24. That made it much better,
but it’s still quite bad. So why not switch from zlib level 9 to zlib
level 1?
I tested this on a core dump of gnome-shell, and while it increased
the size of the .crash file by 24% (68.5 MB to 85.0 MB), it decreased
the needed CPU time by a FACTOR OF EIGHT (58.6 seconds to 7.3
seconds). This tradeoff seems more than worthwhile for this use case.
To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1537635/+subscriptions
References