Not all alerts should not have a bug created for them. Please read on...
[TOC]
- Zoom in on the graph to make sure the alert is not
off-by-one
- Replace
&num_points=XXXX
with&rev=COMMIT_POSITION
in the URL. - It will be obvious from this whether or not the point is off. Use the "nudge" feature to correct it when this happens.
- Replace
- Bisects will not help you.
- For rolls, you can sometimes guess the commit(s) that caused the regression
by looking at the
android-binary-size
trybot result for the roll commit. - Otherwise, use diagnose_bloat.py in a local Android checkout to build all commits locally and find the culprit.
- Go to step 2.
Example:
tools/binary_size/diagnose_bloat.py AFTER_GIT_REV --reference-rev BEFORE_GIT_REV --subrepo v8 --all
- You can usually find the before and after revs in the roll commit message
(example)
- Note that you may need to click through the link for the list of changes
in order to find the actual first commit hash and use that one instead
since some rollers (including v8) use extra commits for tagging not in
master. In the linked example
BEFORE_GIT_REV
would actually be876f37c
and notc1dec05f
.
- Note that you may need to click through the link for the list of changes
in order to find the actual first commit hash and use that one instead
since some rollers (including v8) use extra commits for tagging not in
master. In the linked example
- The regression most likely already occurred in the upstream MonochromePublic.apk target. Look at the graph of Monochrome.apk and MonochromePublic.apk overlaid to find the culprit and de-dupe with upstream alert.
- If no upstream regression was found, look through the downstream commits
within the given date range to find the culprit.
- Via
git log --format=fuller
(be sure to look atCommitDate
and notAuthorDate
)
- Via
- If the culprit is not obvious, follow the steps from the "multiple commits"
section above, filing a bug and running
diagnose_bloat.py
(with--subrepo=clank
).
- If the commit message's
Binary-Size:
footer clearly justifies the size increase, silence the alert. - If the regression is < 100kb and caused by an AFDO roll, silence the alert.
Otherwise, file a bug (TODO: Make this template automatic):
- Change the bug's title from
X%
toXXkb
- Assign to commit author
- Set description to (replacing bold parts):
Caused by "First line of commit message"
Commit: abc123abc123abc123abc123abc123abc123abcd
Link to size graph: https://chromeperf.appspot.com/report?sid=29a24f1d2b8b785551b26d945108889a5a5eed9a83848feb9f93ce8b58b1884d&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!
If the regression is >50kb, add ReleaseBlock-Stable M-## (next branch cut).*
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.
- There is likely nothing that can be done. Translations are expensive.
- Close as
Won't Fix
.
- Ensure
compress="gzip"
is used for allchrome:
pages. - Look at the SuperSize reports from the trybot to look for unexpected resources, or unreasonably large symbols.
- Would a VectorDrawable be better?
- If it's lossy, consider using webp.
- Ensure you've optimized with tools/resources/optimize-png-files.sh.
- There is some Googler-specific guidance as well.
- Look at the SuperSize reports from the trybot to look for unexpected symbols, or unreasonably large symbols.
- If the diff looks reasonable, close as
Won't Fix
. - Otherwise, try to refactor a bit (e.g.
move code out of templates).
- Use //tools/binary_size/diagnose_bloat.py or the android-binary-size trybot to spot-check your local changes.
- If symbols are larger than expected, use the
Disassemble()
feature ofsupersize console
to see what is going on.
- Look at the SuperSize reports from the trybot to look for unexpected methods.
- Ensure any new Java deps are as specific as possible.
- File a bug under Tools > BinarySize with a link to your commit.
- Feel free to email binary-size@chromium.org.
- Bugs requiring sheriffs to take a look at are labeled
Performance-Sheriff
andPerformance-Size
here. - After resolving the bug by finding an owner or debugging or commenting,
remove the
Performance-Sheriff
label.
- IMPORTANT: Check the perf bot page
several times a day to make sure it isn't broken (and ping/file a bug if it is).
- At the very least you need to check this once in the morning and once in the afternoon.
- If you don't and the builder is broken either you or the next sheriff will
have to manually build and diff the broken range (via.
diagnose_bloat.py
) to see if we missed any regressions. - This is necessary even if the next passing build doesn't create an alert because the range could contain a large regression with multiple offsetting decreases.
- Check alert page regularly for new alerts.
- Join g/chrome-binary-size-alerts.
- Deal with alerts as outlined above.