All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=847981

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=fc709fc2186a981be14a381da8c76d95fdd0f01cc417645e678d5012f08b72f8


Bot(s) for this bug's original alert(s):

linux

Assigning to sheriff gbiv@chromium.org because this autoroll is the only CL in range:
Roll AFDO from 68.0.3437.0_rc-r2 to 68.0.3438.0_rc-r1

This CL may cause a small binary size increase, roughly proportional
to how long it's been since our last AFDO profile roll. For larger
increases (around or exceeding 100KB), please file a bug against
gbiv@chromium.org. Additional context:  https://crbug.com/805539 

The AutoRoll server is located here: https://afdo-chromium-roll.skia.org

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.


TBR=gbiv@chromium.org

Change-Id: Ic7ab0978b450ddf7d102c60fd7c2dc93d54e5d57
Reviewed-on: https://chromium-review.googlesource.com/1070002
Commit-Queue: afdo-chromium-autoroll <afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Reviewed-by: afdo-chromium-autoroll <afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#560993}

It looks like the roll to 3437.0_rc-r2 won us 389KB of binary size, then this roll recaptured around 262KB of that win.

Given that the 3437-r2 profile was pretty broken all-around (it caused huge regressions on some Android metrics that I'm looking into, and was a pretty decent binary size regression), I don't think there's anything in particular to do about this. I'm actively trying to figure out how to improve the stability of Chrome when we get a new profile drop, but that's a more general effort.