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

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


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

android-nexus5
android-nexus5X
android-nexus6
android-nexus7v2
android-one
android-webview-nexus6

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8961961475763364752

=== Auto-CCing suspected CL author mythria@chromium.org ===

Hi mythria@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 : Mythri Alle
  Commit : 2d88095699f02011d0d0c7d21bf4f348ae453b20
  Date   : Wed Nov 22 11:48:27 2017
  Subject: Remove v8.browsing_desktop and v8.browsing_mobile benchmarks.

Bisect Details
  Configuration: android_nexus5X_perf_bisect
  Benchmark    : v8.browsing_mobile
  Metric       : total:500ms_window:renderer_eqt:v8_max/browse_media/browse_media_flickr_infinite_scroll
  Change       : 195.48% | 305.5365 -> 902.8065

Revision             Result                  N
chromium@518507      305.536 +- 34.0593      6      good
chromium@518559      288.237 +- 29.8262      6      good
chromium@518585      304.21 +- 20.9208       6      good
chromium@518598      297.241 +- 34.6802      6      good
chromium@518604      295.528 +- 27.6068      6      good
chromium@518607      296.973 +- 33.905       6      good
chromium@518608      299.287 +- 32.3979      6      good
chromium@518609      883.958 +- 48.6959      6      bad       <--
chromium@518610      902.807 +- 30.4844      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=browse.media.flickr.infinite.scroll v8.browsing_mobile

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8961961475763364752


For feedback, file a bug with component Speed>Bisection

Thanks Ulan. On Desktop there are regressions on twitter and flickr on the v8 total:500ms_window:renderer_eqt:v8:execute_max  bucket across all platforms which also causes regressions on the  total:500ms_window:renderer_eqt:v8_max and 
total:500ms_window:renderer_eqt_max. A slight regression (maybe around ~10%) could be explained because RCS is more expensive to compute. This regression is rather large. I will take a look at these two.

On Android also there are several large regressions, I haven't finished looking it yet, but looks like most of them are in v8_execute contributions to eqt too.

On Desktop, there is no regression on v8_execution_wall_clock metrics, but there is a regression on the eqt:v8_execute. The eqt:v8_execute computes the eqt contributions for v8_execution. So, I am not sure what is missing here. 

Data here:
https://chromeperf.appspot.com/report?sid=8bfca44fd6ea71ee00c6ecf0958c7a488abbeadbc332bea804a383c6d2e1496a

I checked traces before and after the change.

There one V8.Execute event that is ~70ms longer after the change:
Start 23,282.984 ms, Wall Duration 249.005 ms
Start 23,239.065 ms, Wall Duration 187.187 ms

That explains the regression in EQT.

I don't know why V8.execute becomes longer, maybe it is the overhead of runtime callstats?

I was expecting the overhead to be 10% - 20%. This one seems to be around 33%. May be it is just the overhead, I tried to look at events around that trace. I was trying to see if some other events which were earlier reported as a separate tasks (because we enable v8.compile trace category) got included into v8.execute now. Though that doesn't seem to be the case. 

 Issue 789448  has been merged into this issue.

 Issue 789448  has been merged into this issue.

 Issue 789449  has been merged into this issue.

 Issue 788626  has been merged into this issue.

Marking it as won't fix. When I looked at it last, everything looked ok. May there are also some timing issues which increases the overhead more than expected in some cases.