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

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


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

android-nexus5

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12881f92a40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/12881f92a40000

cut SkMaskBlurFilter code size by about half by mtklein@chromium.org
https://skia.googlesource.com/skia/+/b06be0e8b909f7237dda6817bc6301826f7ede3f
68.43 → 70.15 (+1.722)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

This is the sort of speed/size tradeoff we'd expect from that change.  Probably wouldn't want to land the CL the other way around (double code size for 3% speedup).

There was a time when we were collecting performance tradeoffs we're making.

Are we still doing that?

I'm not familiar with that.

Sorry Mike, should have explictly mentioned +benhenry@, +ushesh@, to whom I intended to address that question.

It's been a while, but we have collected tradeoffs in the past. It might be good to do that again.

go/chrome-speed-tradeoffs