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

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


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

android-nexus6

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

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

Hi treib@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 : Marc Treib
  Commit : 453cdca9a87018ae26b911899beb6394eaa17ecd
  Date   : Fri Oct 20 11:29:19 2017
  Subject: embeddedSearch API: Expose static functions

Bisect Details
  Configuration: android_nexus6_perf_bisect
  Benchmark    : v8.runtimestats.browsing_mobile
  Metric       : V8 C++:duration_avg/browse_shopping/browse_shopping_avito
  Change       : 2.92% | 7605.61583333 -> 7827.5205

Revision             Result                  N
chromium@510393      7605.62 +- 202.439      6      good
chromium@510400      7568.72 +- 117.548      6      good
chromium@510401      7759.25 +- 346.493      9      bad       <--
chromium@510402      7737.81 +- 135.29       6      bad
chromium@510403      7715.33 +- 45.3056      6      bad
chromium@510406      7768.27 +- 81.5635      6      bad
chromium@510418      7827.52 +- 115.891      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.shopping.avito v8.runtimestats.browsing_mobile

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

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


For feedback, file a bug with component Speed>Bisection

Huh, this is weird:
- Basically the only change here is that we call blink::WebLocalFrame::FrameForCurrentContext a few times, which hopefully shouldn't be that expensive?!
- And anyway, the change should affect only desktop, not Android.

I'll investigate...

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

I've checked locally that none of the changed code gets executed on Android. (It *is* compiled on Android, but I don't see how a change in never-executed code could cause this kind of perf regression.)

Looking at the graph, it's pretty clear that there is a regression of about 2-3%. Since that isn't much above the noise level, let's see what the second bisect says.
It's also a bit suspicious that the regression exists only on a single bot.

CCing test owner in case they have any ideas.

=== Auto-CCing suspected CL author v8-autoroll@chromium.org ===

Hi v8-autoroll@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 : v8-autoroll
  Commit : 798695ed8f30db273c2e0fabaa5e9337ee250be2
  Date   : Fri Oct 20 08:28:47 2017
  Subject: Version 6.4.62

Bisect Details
  Configuration: android_nexus6_perf_bisect
  Benchmark    : v8.runtimestats.browsing_mobile
  Metric       : V8 C++:duration_avg/browse_shopping/browse_shopping_avito
  Change       : 4.33% | 7638.47666667 -> 7969.205

Revision                           Result                  N
chromium@510393                    7638.48 +- 138.861      6      good
chromium@510406                    7722.69 +- 56.0308      6      good
chromium@510408                    7677.78 +- 107.575      6      good
chromium@510408,v8@34b614e645      7767.48 +- 136.151      6      good
chromium@510408,v8@4fc47a2742      7772.02 +- 138.277      6      good
chromium@510408,v8@798695ed8f      7886.95 +- 155.755      9      bad       <--
chromium@510409                    7942.14 +- 117.735      6      bad
chromium@510412                    7914.45 +- 163.709      6      bad
chromium@510418                    7969.21 +- 92.2555      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.shopping.avito v8.runtimestats.browsing_mobile

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

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


For feedback, file a bug with component Speed>Bisection

I am not sure, I don't see a strong suspect in the regression range. These are the changes: https://chromium.googlesource.com/v8/v8/+log/477a9850..798695ed. 

The regression is real I think. It is above the noise level and we can also see a similar behaviour on other bots. https://chromeperf.appspot.com/report?sid=f7ef262305bc5b3004c945dac4579c277fa35cf2b524b4dd61e6ae43314bdbf1. On Nexus5 it did not cause perf alert but there is a regression in a similar range. 

A v8 roll certainly looks like a more likely culprit than my CL.
This looks quite similar to  bug 777309 , but the regression ranges don't quite match up. Could they still be related?

My change in fact went into the build before the marked one, namely it's in V8 6.4.60 roll. It was expected to affect the performance with RCS enabled, so I think it is the culprit for the regression around build 510401. We already have a  bug 777309  for that.

I'll keep this bug open to track the second regression, which occurred around build  510408. Needs to be investigated further.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e9c53b9c528ffc8ad953c01aeaedfb77c98df508

commit e9c53b9c528ffc8ad953c01aeaedfb77c98df508
Author: Marc Treib <treib@chromium.org>
Date: Fri Nov 03 11:00:55 2017

Cleanup: don't compile embeddedSearch API implementation on Android

According to "tools/binary_size/diagnose_bloat.py HEAD -v", this
reduces apk size by about 24kB:
MonochromePublic.apk_Breakdown (-24,576 bytes)
        -2 bytes Zip Overhead
   -24,576 bytes Native code size
        +2 bytes Package metadata size
MonochromePublic.apk_Specifics
   -24,576 bytes normalized apk size
   -24,576 bytes main lib size

Bug: 778665,  627747 
Change-Id: Ic452176c1345d9d1b7783e38b8019a0974151895
Reviewed-on: https://chromium-review.googlesource.com/743728
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Marc Treib <treib@chromium.org>
Cr-Commit-Position: refs/heads/master@{#513740}
[modify] https://crrev.com/e9c53b9c528ffc8ad953c01aeaedfb77c98df508/chrome/renderer/BUILD.gn
[modify] https://crrev.com/e9c53b9c528ffc8ad953c01aeaedfb77c98df508/chrome/renderer/chrome_content_renderer_client.cc
[modify] https://crrev.com/e9c53b9c528ffc8ad953c01aeaedfb77c98df508/chrome/renderer/chrome_render_frame_observer.cc
[modify] https://crrev.com/e9c53b9c528ffc8ad953c01aeaedfb77c98df508/chrome/test/BUILD.gn