=== Auto-CCing suspected CL author mek@chromium.org ===
Hi mek@chromium.org, the bisect results pointed to your CL, please take a look at the
results.
=== BISECT JOB RESULTS ===
Perf regression found with culprit
Suspected Commit
Author : Marijn Kruisselbrink
Commit : 17c5e2fb29bf938660314048ff85346670ab6abe
Date : Sat Sep 30 23:47:47 2017
Subject: Onion Soupify MessagePort
Bisect Details
Configuration: android_nexus6_perf_bisect
Benchmark : system_health.common_mobile
Metric : cpu_time_percentage_avg/long_running_tools/long_running_tools_gmail-foreground
Change : 1170.86% | 0.0786941413119 -> 1.00009449442
Revision Result N
chromium@505469 0.0786941 +- 0.00305851 6 good
chromium@505477 0.0784801 +- 0.00128879 6 good
chromium@505479 0.0797289 +- 0.00379716 6 good
chromium@505480 0.999772 +- 0.00337436 6 bad <--
chromium@505481 0.999742 +- 0.00238849 6 bad
chromium@505485 1.00043 +- 0.00260374 6 bad
chromium@505500 1.00009 +- 0.00387566 6 bad
To Run This Test
src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=long.running.tools.gmail.foreground system_health.common_mobile
More information on addressing performance regressions:
http://g.co/ChromePerformanceRegressions
Debug information about this bisect:
https://chromeperf.appspot.com/buildbucket_job_status/8966816682546874064
For feedback, file a bug with component Speed>Bisection
I've reverted the CL that depended on the problematic one, so hopefully that one should revert cleanly now. No idea yet what would cause this regression though. And as you say opening the after trace seems to cause chrome to get very unhappy...
Trying to run the (desktop version of) that long_running:tools:gmail-foreground benchmark locally fails with "OverflowError: size does not fit in an int" when trying to gzip the serialized trace data... Obviously something really wrong here, just not sure what.
Thanks. What seems to be the main difference is that the bad traces have tons upon tons of InputLatency related events. But that probably is just a symptom of whatever else is wrong. At least it's fairly trivial to reproduce this locally. (and fwiw the revert seems to have almost made it through the CQ)
Okay, I'm pretty sure I figured out the bug (and its fix https://chromium-review.googlesource.com/c/chromium/src/+/699159).
Should I land the fix directly, or still revert first and then reland with the fix included? (sorry, the previous revert attempt failed with merge conflicts after all trybots passed)
Comment 1 by 42576172...@developer.gserviceaccount.com
, Oct 2 2017