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

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


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

chromium-rel-win7-dual

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

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

Hi rmcilroy@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 : Ross McIlroy
  Commit : 3e19d72377f985545fc4966dcfad76442280d68f
  Date   : Tue Jul 18 09:43:19 2017
  Subject: [Compiler] Move creation of SharedFunctionInfo later in compile.

Bisect Details
  Configuration: win_perf_bisect
  Benchmark    : media.tough_video_cases_tbmv2
  Metric       : memory:chrome:all_processes:reported_by_chrome:peak_size_avg/video.html?src_tulip2.vp9.webm
  Change       : 2.82% | 290372.0 -> 298564.0

Revision                           Result             N
chromium@487395                    290372 +- 0.0      6      good
chromium@487445                    290372 +- 0.0      6      good
chromium@487452                    290372 +- 0.0      6      good
chromium@487452,v8@2b5a36d571      290372 +- 0.0      6      good
chromium@487452,v8@3e19d72377      298564 +- 0.0      6      bad       <--
chromium@487452,v8@b56b94bebc      298564 +- 0.0      6      bad
chromium@487453                    298564 +- 0.0      6      bad
chromium@487454                    298564 +- 0.0      6      bad
chromium@487455                    298564 +- 0.0      6      bad
chromium@487458                    298564 +- 0.0      6      bad
chromium@487470                    298564 +- 0.0      6      bad
chromium@487494                    298564 +- 0.0      6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=video.html.src.tulip2.vp9.webm media.tough_video_cases_tbmv2

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

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


For feedback, file a bug with component Speed>Bisection

 Issue 747047  has been merged into this issue.

 Issue 747532  has been merged into this issue.

 Issue 747531  has been merged into this issue.

 Issue 747533  has been merged into this issue.

 Issue 747527  has been merged into this issue.

 Issue 747528  has been merged into this issue.

 Issue 747529  has been merged into this issue.

 Issue 747530  has been merged into this issue.

 Issue 747535  has been merged into this issue.

 Issue 747534  has been merged into this issue.

 Issue 747534  has been merged into this issue.

 Issue 748078  has been merged into this issue.

 Issue 748081  has been merged into this issue.

 Issue 748283  has been merged into this issue.

I had a look into this. It seems like the peak memory regression is caused by the fact that this CL changes the order in which we compile the outer function and it's eagerly compiled (IIFE) inner functions. Before we would compile inner functions first, now we compile outer the outer function first.

It seems like this ordering impacts the peak zone memory requirements in these tests.  Given that all the regressions are in tough_video_cases_tbmv2, all are about the same size, and there are no regressions in any other pagesets, my suspicion is that this is triggered by a JS function common to this test-case and not the pages themselves.

Further work should split out the compilation and finalization of inner and outer functions into different phases, which should hopefully address this regression.

No longer actionable (might be have recovered now anyway), and no regressions seen elsewhere. Closing.