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

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


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

chromium-rel-mac-retina

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

=== BISECT JOB RESULTS ===
Bisect was unable to run to completion

Error: INFRA_FAILURE

The bisect was able to narrow the range, you can try running with:
  good_revision: 93ecf9e5694aa3feed507e4a055fa8a613538c64
  bad_revision : 44939404f848516e74a9a0c8d84e31323461fa79

If failures persist contact the team (see below) and report the error.


Bisect Details
  Configuration: mac_retina_perf_bisect
  Benchmark    : system_health.common_desktop
  Metric       : load:energy_sum/long_running_tools/long_running_tools_gmail-foreground

Revision             Result                  N
chromium@490851      372.076 +- 269.814      18      good
chromium@492841      340.703 +- 6.93706      5       good
chromium@493836      346.186 +- 14.4735      7       good
chromium@494333      375.518 +- 259.393      14      good
chromium@494582      355.49 +- 21.2857       8       good
chromium@494706      352.858 +- 12.8436      6       good
chromium@494830      484.294 +- 401.902      10      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=long.running.tools.gmail.foreground system_health.common_desktop

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

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


For feedback, file a bug with component Speed>Bisection

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

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

Hi alexmos@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 : Alex Moshchuk
  Commit : 71f48559772345f1005a0e24eb27b01feada9439
  Date   : Wed Aug 16 16:20:00 2017
  Subject: Change error pages to use a new chrome-error:// scheme.

Bisect Details
  Configuration: mac_retina_perf_bisect
  Benchmark    : system_health.common_desktop
  Metric       : load:energy_sum/long_running_tools/long_running_tools_gmail-foreground
  Change       : 28.75% | 271.357840366 -> 349.380773231

Revision             Result                  N
chromium@494706      271.358 +- 42.9558      6      good
chromium@494768      276.041 +- 10.4022      6      good
chromium@494799      265.255 +- 19.513       6      good
chromium@494807      268.166 +- 25.6499      6      good
chromium@494808      262.273 +- 25.8631      6      good
chromium@494809      348.339 +- 26.3678      6      bad       <--
chromium@494811      403.467 +- 219.509      5      bad
chromium@494815      355.101 +- 7.75978      6      bad
chromium@494830      349.381 +- 25.7004      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=long.running.tools.gmail.foreground system_health.common_desktop

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

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


For feedback, file a bug with component Speed>Bisection

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

I'm not sure how my CL could cause this regression.  It refactored the URL used for loading error pages, which should not impact performance.  Moreover, AFAICT this test is not supposed to load any error pages; it just loads gmail and lets it run for a while.  The graph also looks a little suspicious -- it jumped again in the next iteration, and it jumped down to the previous level a couple of times thereafter. I've kicked off another bisect to see what happens, but for now, I'll unassign myself to let the perf folks follow up on this, per instructions on [1].

[1] https://chromium.googlesource.com/chromium/src/+/master/docs/speed/addressing_performance_regressions.md#If-you-don_t-believe-your-CL-could-be-the-cause.

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

Suspected Commit
  Author : Alex Moshchuk
  Commit : 71f48559772345f1005a0e24eb27b01feada9439
  Date   : Wed Aug 16 16:20:00 2017
  Subject: Change error pages to use a new chrome-error:// scheme.

Bisect Details
  Configuration: mac_retina_perf_bisect
  Benchmark    : system_health.common_desktop
  Metric       : load:energy_sum/long_running_tools/long_running_tools_gmail-foreground
  Change       : 26.73% | 229.135703854 -> 281.762289637

Revision             Result                  N
chromium@490851      229.136 +- 13.2445      6       good
chromium@492841      228.807 +- 15.5518      5       good
chromium@493836      220.91 +- 11.9376       5       good
chromium@494333      208.356 +- 74.189       6       good
chromium@494582      218.653 +- 9.45653      6       good
chromium@494706      221.779 +- 18.2152      14      good
chromium@494768      235.434 +- 155.804      14      good
chromium@494799      222.827 +- 15.5299      6       good
chromium@494807      220.82 +- 105.174       9       good
chromium@494808      218.393 +- 11.3493      6       good
chromium@494809      278.646 +- 16.7778      8       bad       <--
chromium@494811      280.967 +- 80.3888      13      bad
chromium@494815      285.22 +- 19.2587       9       bad
chromium@494830      281.762 +- 93.4503      14      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=long.running.tools.gmail.foreground system_health.common_desktop

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

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


For feedback, file a bug with component Speed>Bisection

Ned - can you take a look? It seems unlikely this change caused this, but looking at the diff, it's unclear to me what's going on.

ksakamoto: this seems really similar to  bug 755983 , where the same CL made loading metrics report for the error page. Any thoughts on whether this could be a sign of a bad recording?

Yeah, loading metric has been special-casing the error pages, and it was broken until http://crrev.com/c/680395.

It seems power_metric uses loading_metric inside it, so it's likely that there're some error pages in this benchmark run.

So what's the fix here? Rerecord the page? In WPR or wpr-go?

I believe the fix is making sure power_metric reuse loading_metric's code correctly for computing load:energy_sum. It's more likely that this invovles fixing the metrics code.

Assign to Charlie as power metrics owner.

It sounds like the loading metric has special behavior for the error page and that, when that special behavior broke due to the error page's URL changing, our metric also broke. This seems if anything like confirmation that we _are_ using the loading metric correctly, because we both broke and were fixed with the loading metric. Unfortunately, I can't confirm this with the long running tools gmail foreground story, because it was disabled shortly after this regression took place. I'm going to close this as WontFix.

Wait, shouldn't we understand why the benchmark is loading an error page???