Googlers, see also: go/chrome-binary-size-garderning
Not all alerts should not have a bug created for them. Please read on...
&num_points=XXXX
with &rev=COMMIT_POSITION
in the URL.android-binary-size
trybot result for the roll commit, or by looking for “Binary-Size:” footers in the blamelist.--apply-patch
with the fixing commit (last one in the range).Example:
tools/binary_size/diagnose_bloat.py AFTER_GIT_REV --reference-rev BEFORE_GIT_REV --all [--subrepo v8] [--apply-patch AFTER_GIT_REV]
BEFORE_GIT_REV
would actually be 876f37c
and not c1dec05f
.Binary-Size:
footer clearly justifies the size increase, silence the alert.Otherwise, file a bug.
X%
to XXkb
Caused by “First line of commit message”
Commit: abc123abc123abc123abc123abc123abc123abcd
Link to size graph: https://chromeperf.appspot.com/report?sid=6269078068c45a41e23f5ee257da65d3f02da342849cdf3bde6aed0d5c61e450&num_points=10&rev=$CRREV
Link to trybot result: https://ci.chromium.org/p/chromium/builders/luci.chromium.try/android-binary-size/$TRYJOB_NUMBERDebugging size regressions is documented at: https://chromium.googlesource.com/chromium/src/+/main/docs/speed/apk_size_regressions.md#Debugging-Apk-Size-Increase
Based on the trybot result: 20kb of native code, 8kb of pngs. (or some other explanation as to what caused the growth).
It's not clear to me whether or not this increase was expected.
Please have a look and either:
- Close as “Won't Fix” with a short justification, or
- Land a revert / fix-up.
Optional addition:
It typically takes about a week of engineering time to reduce binary size by 50kb so we'd really appreciate you taking some time exploring options to address this regression!
It typically takes about a week of engineering time to reduce binary size by 50kb so it's important that an effort is made to address all new regressions. For more about binary size, see binary_size_explainer.md.
Figure out which file within the .apk
increased (native library, dex, pak resources, etc.) by looking at the trybot results or size graphs that were linked from the bug (if it was not linked in the bug, see above).
See //docs/speed/binary_size/metrics.md for a description of high-level binary size metrics.
See //tools/binary_size/README.md for a description of binary size tools.
See optimization advice.
If you aren't sure where to start and would like help with the investigation, comment on the bug or reach out to binary-size@chromium.org to ask for help.
If you are pretty sure that your implementation is optimal(ish), add a comment to the bug with the following:
Close the bug as “Won't Fix”.