Chrome Speed

How to Deal with Android Size Alerts

Not all alerts should not have a bug created for them. Please read on...

Step 1: Identify the Commit

MonochromePublic.apk Alerts (Single Commit)

  • 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.

MonochromePublic.apk Alerts (Multiple Commits or Rolls)

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 be 876f37c and not c1dec05f.

Monochrome.apk Alerts

  • 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 at CommitDate and not AuthorDate)
  • 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).

Step 2: File Bug or Silence Alert

If the code clearly justifies the size increase, silence the alert.

Otherwise, file a bug (TODO: Make this template automatic):

  • Change the bug's title from X% to XXkb
  • 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=bb23072657e2d7ca892a1c3fa4643b1ee29b3a0a44d0732adda87168e89c0380&num_points=10&rev=480214

Debugging 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 graph: 20kb of native code, 8kb of pngs.

Option 1:

It looks to me that the size increase is expected.
Feel free to close as “Won't Fix” unless you can see some way to reduce size.

Option 2:

It looks like this increase was probably unexpected or might be avoidable.
Please have a look and either:

  1. Close as “Won't Fix” with a short justification, or
  2. Land a revert / fix-up.

Option 3:

It's not clear to me whether or not this increase was expected.
Please have a look and either:

  1. Close as “Won't Fix” with a short justification, or
  2. Land a revert / fix-up.

Optional addition for commits > 75kb:

It typically takes about a week of engineering time to reduce binary size by 100kb so we'd really appreciate you taking some time exploring options to address this regression!

If you went with Option 2, and the regression is > 50kb, add ReleaseBlock-Stable M-6- (next branch cut).

Once the initial bug is filed, add a follow-up comment with the output of:

tools/binary_size/diagnose_bloat.py GIT_REV --cloud

Debugging Apk Size Increase

Step 1: Identify what Grew

Figure out which file within the .apk increased (native library, dex, pak resources, etc) by looking at the breakdown in the size graphs linked to in the bug (if it was not linked in the bug, see above).

See //docs/speed/binary_size/metrics.md for a description of the metrics we track.

Step 2: Analyze

Growth is from Translations

  • There is likely nothing that can be done. Translations are expensive.
  • Close as Won't Fix.

Growth is from Native Resources (pak files)

Growth is from Images

Growth is from Native Code

  • Use //tools/binary_size/diagnose_bloat.py to show a diff of ELF symbols.
    • Googlers should use the speedy --cloud option. E.g.:
    • tools/binary_size/diagnose_bloat.py 0f30c9488bd2bdc1db2749cd4683994a764a44c9 --cloud
  • Paste the diff into the bug.
  • If the diff looks reasonable, close as Won't Fix.
  • Otherwise, try to refactor a bit (e.g. move code out of templates).
  • If symbols are larger than expected, use the Disassemble() feature of supersize console to see what is going on.

Growth is from Java Code

Growth is from “other lib size” or “Unknown files size”

  • File a bug against agrieve@ to fix resource_sizes.py.
  • ...or fix it yourself. This script will output the list of unknown filenames.

You Would Like Assistance

For Binary Size Sheriffs

Step 1: Check work queue daily

  • Bugs requiring sheriffs to take a look at are labeled Performance-Sheriff and Performance-Size here.
  • After resolving the bug by finding an owner or debugging or commenting, remove the Performance-Sheriff label.

Step 2: Check alerts regularly

  • 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 binary-size-alerts@chromium.org. Eventually it will be all set up.
  • Deal with alerts as outlined above.