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

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


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

Android Builder

gbiv@ - just wanted to double check to make sure that this growth was expected. Are we likely to see regressions often with profile rolls, and if so should we be filing size regression bugs to investigate?

Deleted: diff_results.txt 531 KB

diff_results.txt 531 KB View Download

> Are we likely to see regressions often with profile rolls

Yeah. As profiles age and become less accurate, clang will begin optimizing Chrome less aggressively for speed, and more for size. When we check in a fresh profile, we should see the opposite effect.

> and if so should we be filing size regression bugs to investigate?

If there's a big change (say, ≥100KB), please do file a bug and I'll look at it. ~40KB or so, though, is expected, especially given that the previous profile was well over a week old. :)

I'm making an autoroller for these; I'll have it summarize this in its commit messages, as well.

Thank you!

(To be clear: the ≥100KB figure was sort of just a gut feel. If that sounds too high, feel free to pick a lower number; just let me know so I can note that in my bot's commit messages. :) )

Interesting!

And 100 KB sounds good to me; I'm assuming that these will mostly won't be actionable anyway? +agrieve.

Also, thanks for your work implementing AFDO for Chrome, the perf improvements are really impressive :).

Yeah. If we hit a particularly terrible regression, all we can really immediately do is roll back the profile or turn off AFDO for the pieces of code that are causing issues.

If any regression can be classified as a bug in clang/LLVM or an issue with the profiles we're getting, either I can fix that, or I'm within nerf gun distance of someone who can. ;)