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

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


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

Android Nexus5 Perf
android-nexus5x-perf

rendering.mobile - Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12a52165640000

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

Revert "Count number of active touches in TouchActionFilter" by falken@chromium.org
https://chromium.googlesource.com/chromium/src/+/284cfbd5863b68dd8b075910b2b8bca8b9b0ad2b
1.542 → 2.097 (+0.5543)

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

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

My change just reverted a CL that added DumpWithoutCrashing().

I don't know who owns this benchmark. Guessing the component and cc Ned and Sadrul based on https://chromium-review.googlesource.com/1129821

Issue 883856 has been merged into this issue.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14410f7ae40000

This seems not a regression to me. I started another pinpoint job to see if we finds other suspect.  

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

Revert "Count number of active touches in TouchActionFilter" by falken@chromium.org
https://chromium.googlesource.com/chromium/src/+/284cfbd5863b68dd8b075910b2b8bca8b9b0ad2b
thread_raster_cpu_time_per_frame: 1.363 → 2.079 (+0.7156)

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

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

My change just reverted a CL that added DumpWithoutCrashing().

The regression in thread_total_all_cpu_time_per_frame is pretty big. It would be useful to understand what's going on.

Assigning to xidachen@ as the author of the original CL (https://chromium-review.googlesource.com/c/chromium/src/+/1196696). It looks like the CL does things in addition to just adding DumpWithoutCrashing(). So perhaps you could re-land those parts of the original CL?

/cc+ sahel@ and nzolghadr@ from input team.

I don't understand this. The regression is not pointing at the original CL that adds the DumpWithoutCrashing, but rather pointing at the CL that reverts it. IMO, the original CL that adds DumpWithoutCrashing is likely to cause the regression, not the other way around.

Also, the CL has been reverted, but the regression still exists, so I don't know what's the next action.

There's a dip in the metric for the original CL (in range 587885 - 587938).
There's a spike after the revert (in range 588770 - 588807).

Are the changes other than DumpWithoutCrashing() in the original CL no-ops?

Yes, the original CL does some other checks, in additional to the DumpWithoutCrashing. But it does more work, not remove any existing work. So I don't understand how reverting the CL could ever cause regression.

Hm, that's kind of weird. pinpoint did find the same CL in two different tries.

nzolghadr@, sahel@: any ideas?

Over to nzolghadr@ to see if the drop and then the subsequent bump makes sense, and if there's anything farther to do, or just wontfix.