Supersize: Store uncompressed sizes or compressed sizes or both? |
||
Issue descriptionProblem with storing only compressed sizes: - A single new string causes sizes for all other pak entries to shift around - A single new resource or other file causes sizes for all other ".other" files to shift around Benefit with storing compressed sizes: - Magnitude of symbol size changes actually correspond almost exactly to Monochrome.apk size changes. Problem with storing only uncompressed sizes: - Much larger numbers than actually delivered in apk file Benefit with storing uncompressed sizes: - When symbols are added or removed, it's easy to see which new string or resource was added and exactly how big it was in relation to other symbols
,
Mar 28 2018
Perhaps the best of both worlds (and some negative of both worlds) is to do the same thing for dex files as pak files, use a relatively correct constant to represent zip compression. This gets us close to the ballpark of compressed sizes and also is stable between diffs.
,
Mar 29 2018
I don't think it's worth doing for dex. Thanks to .vdex / .odex files, the uncompressed size is more relevant than the compressed size anyways.
,
Mar 29 2018
Sounds good. It's about 55% compression ratio, compressed dex is ~2.5MB and uncompressed is ~6MB. Uncompressed it will stay then. |
||
►
Sign in to add a comment |
||
Comment 1 by agrieve@chromium.org
, Mar 26 2018