Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?
On 2021-03-06 11:11, Jakub Wilk wrote:
* Elana Hashman <ehashman@debian.org>, 2021-02-17, 11:06:
Would you be able to research some representative slice of popular
packages that would be affected by the policy change (at least 10) and
share the on-disk sizes with compression vs. without?
Not exactly what you asked Niels for, but...
A few months ago I recompressed whole buster/main/amd64 to see what
the effect of ditching --compress-debug-sections would be.
Raw data for this experiment is available here:
https://github.com/jwilk/lets-shrink-dbgsym/releases/download/20200708/buster-main-amd64-20200708.tsv.xz
The columns are:
* file name
* original .deb size
* recompressed .deb size
* original installed size
* recompressed installed size
Note that some of the .deb size savings might be caused by the fix for
#868674 (for packages that haven't been rebuilt since the fix).
Hi Jakub,
This is very helpful. Using this file, I have calculated the following
three aggregates:
1. % size between original and recompressed .deb
2. % size between original and recompressed install size
3. size difference in bytes between original and recompressed install
size
I then performed a quartile analysis on it.
Recompressed size is X% of original .deb:
Min 3.97%
25% 65.45%
Median 74.73%
75% 82.64%
Max 105.01%
Installed size of recompressed is X% of original installed size:
Min 100.06%
25% 230.72%
Median 256.76%
75% 292.76%
Max 4267.38%
Size difference between recompressed and original installed size, is X
bytes:
Min 20480 (20KB)
25% 89088 (90KB)
Median 404480 (404KB)
75% 2461184 (2.5MB)
Max 5728869376 (5.72GB)
So I think we can conclude the following:
- In essentially all cases, recompressed deb has a size improvement over
the original.
- In all cases, the installed size of the debug symbols is larger,
usually about 2-3x the original installed size.
- In all but the largest cases, that size difference is negligable.
However, the large cases have quite an extreme difference.
Hence, I think the tail end of large packages will guide this decision,
and Josh very helpfully provided an analysis of those already!
Because of the extreme difference for the large packages, and because
many of those packages are relatively popular, I think I am inclined to
maintain the status quo, i.e. with --compress-debug-section enabled by
default. I am open to being convinced otherwise :)
Cheers,
- e
Reply to: