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.--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 (TODO: Make this template automatic):
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/+/master/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.
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 have spent O(days) trying to reduce the size overhead of your patch and are pretty sure that your implementation is optimal(ish), then add a comment to the bug with the following:
Close the bug as “Won't Fix”.
Here is the rotation and calendar.
Performance-Sheriff
and Performance-Size
here.Performance-Sheriff
label.