New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 825838 link

Starred by 0 users

Issue metadata

Status: WontFix
Owner:
OOO until Feb 4th
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Supersize: Store uncompressed sizes or compressed sizes or both?

Project Member Reported by wnwen@chromium.org, Mar 26 2018

Issue description

Problem 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
 
Components: Tools>BinarySize

Comment 2 by wnwen@chromium.org, 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.
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.

Comment 4 by wnwen@chromium.org, Mar 29 2018

Status: WontFix (was: Assigned)
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