Ping? It’s still really frustrating to have the entire system go unresponsive for a minute just because gnome-shell crashed and apport won’t let it restart until it’s finished compressing the core dump.
If you’re not willing to go all the way to zlib level 1, can we at least proceed with going down to 5 like you suggested? Alternatively, python3-brotli entered Ubuntu shortly after my original report. brotli level 2 compresses faster than zlib level 1 with smaller output than zlib level 9, while brotli level 1 is as almost as fast as lz4 with output size like zlib level 5! I don’t have the crash dump I used for the tests above, so here are some tests on a somewhat smaller one. zlib.compressobj(level=1) time=7.1 size=41822029 zlib.compressobj(level=2) time=7.1 size=40718379 zlib.compressobj(level=3) time=7.4 size=39638807 zlib.compressobj(level=4) time=13.1 size=31197301 zlib.compressobj(level=5) time=13.9 size=30423373 zlib.compressobj(level=6) time=15.1 size=29763741 zlib.compressobj(level=7) time=16.3 size=29526183 zlib.compressobj(level=8) time=25.6 size=29191955 zlib.compressobj(level=9) time=39.2 size=29067237 bz2.BZ2Compressor(compresslevel=1) time=25.0 size=25198553 bz2.BZ2Compressor(compresslevel=9) time=30.6 size=23280287 lz4.compress time=0.9 size=50649857 lz4.compressHC time=5.4 size=40462669 brotli.Compressor(quality=1) time=1.2 size=30559841 brotli.Compressor(quality=2) time=3.8 size=26162317 brotli.Compressor(quality=3) time=6.2 size=26256343 brotli.Compressor(quality=4) time=8.7 size=24982273 brotli.Compressor(quality=5) time=29.2 size=21744749 brotli.Compressor(quality=6) time=45.5 size=21502521 brotli.Compressor(quality=7) time=81.7 size=21355153 brotli.Compressor(quality=8) time=145.9 size=21249997 If a crash could be recorded in a second instead of a minute with almost no size difference, I’d call that a win. -- 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
