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

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


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

win-high-dpi

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

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

Hi tzik@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 : tzik
  Commit : dacad9a5d42f6b1f485aa347fa5b36bf7374286e
  Date   : Mon Oct 09 04:21:17 2017
  Subject: Make WTF::RefPtr an alias of scoped_refptr

Bisect Details
  Configuration: winx64_high_dpi_perf_bisect
  Benchmark    : blink_perf.bindings
  Metric       : id-getter/id-getter
  Change       : 13.90% | 352.696770496 -> 303.676031355

Revision             Result                  N
chromium@507310      352.697 +- 14.9224      6      good
chromium@507320      352.595 +- 16.5136      6      good
chromium@507325      354.8 +- 7.07443        6      good
chromium@507326      353.507 +- 11.0509      6      good
chromium@507327      300.532 +- 56.0639      6      bad       <--
chromium@507329      303.676 +- 74.0507      6      bad

Please refer to the following doc on diagnosing blink_perf regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/speed/benchmark_harnesses/blink_perf.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests blink_perf.bindings

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

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


For feedback, file a bug with component Speed>Bisection

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

commit 3e04193c7395b114dda5c889d2e402e44b660caa
Author: tzik <tzik@chromium.org>
Date: Mon Oct 16 17:29:30 2017

Add a free function version of swap for scoped_refptr

RefPtr had swap() as a free function, and scoped_refptr doesn't. So,
after RefPtr merged to scoped_refptr, each swap() callsites fell back
to inefficient std::swap(), that hurts performance. Especially,
std::sort() and std::priority_queue() are badly affected.

This CL adds the missing free function version of swap() to fix the
regression.

Bug:  774107 ,  763844 
Change-Id: I9598e0a1e90d2b0c2b5f44d1ed108a64c85ca6d6
Reviewed-on: https://chromium-review.googlesource.com/721099
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#509086}
[modify] https://crrev.com/3e04193c7395b114dda5c889d2e402e44b660caa/base/memory/scoped_refptr.h

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

Hm, swap() was a cause of the regression around the rasterization, but there seems another around id-getter...

=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : tzik
  Commit : dacad9a5d42f6b1f485aa347fa5b36bf7374286e
  Date   : Mon Oct 09 04:21:17 2017
  Subject: Make WTF::RefPtr an alias of scoped_refptr

Bisect Details
  Configuration: winx64_high_dpi_perf_bisect
  Benchmark    : blink_perf.bindings
  Metric       : id-getter/id-getter
  Change       : 10.30% | 354.566050529 -> 318.028383029

Revision             Result                  N
chromium@507310      354.566 +- 21.0207      9      good
chromium@507320      355.839 +- 8.56231      6      good
chromium@507325      352.973 +- 8.6634       6      good
chromium@507326      354.481 +- 4.01788      6      good
chromium@507327      298.732 +- 69.1274      6      bad       <--
chromium@507329      318.028 +- 80.0206      6      bad

Please refer to the following doc on diagnosing blink_perf regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/speed/benchmark_harnesses/blink_perf.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests blink_perf.bindings

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

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


For feedback, file a bug with component Speed>Bisection

Let me mark this as WontFix. As my change shuffled the inlining, some tests are improved and others are regressed.
In this case, scoped_repftr<>::operator->() seems to perturb the inlining scores on every callers, and that affected the chains of function inlining.

As we can't specify where the compiler should inline a function finer than inline/ALWAYS_INLINE, I think there's no way to adjust the inlining to fit  every benchmarks.

Feel free to reopen this if this benchmark is critically important.