You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Starting v1.5.6, zstd at high compression levels features a better compression ratio on 32-bit structures. The .debug_str_offsets section is a pretty good example of this.
Note that compression at level 19 is very slow, and the mentioned optimization only applies to sections where there are lots of 32-bit integers. It will likely not yield benefits for ULEB128-dominated sections. We should test ratio for each section and build a list of sections where zstd-19 is beneficial.
I propose that we introduce new options for --compress-debug-sections:
zstd-3 - Level 3, would be equivalent to current behavior of zstd
zstd- Level 19 for 32-bit integer sections, level 3 for the rest
zstd-19 - Level 19 for everything, in case one is seeking the best ratio
The text was updated successfully, but these errors were encountered:
It feels a bit odd to me that we need to manually optimize compression levels. Ideally, zstd should (and I believe could) detect that the data being compressed contains lots of 32-bit integers and compress accordingly. Did you know why they can't do that?
facebook/zstd#2832 (comment) mentions that:
Note that compression at level 19 is very slow, and the mentioned optimization only applies to sections where there are lots of 32-bit integers. It will likely not yield benefits for ULEB128-dominated sections. We should test ratio for each section and build a list of sections where zstd-19 is beneficial.
I propose that we introduce new options for
--compress-debug-sections
:zstd-3
- Level 3, would be equivalent to current behavior ofzstd
zstd
- Level 19 for 32-bit integer sections, level 3 for the restzstd-19
- Level 19 for everything, in case one is seeking the best ratioThe text was updated successfully, but these errors were encountered: