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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgztScsQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjpKj4AkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjuevwwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjsmb-AkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjuevgwkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgztSGqAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjpu0pQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjq727ggM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgzqSF4QkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjoWCtgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjq_6sAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjoTjtgsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjs3YvAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgjvzH4AoM


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

chromium-rel-mac-retina
chromium-rel-mac11
chromium-rel-mac11-air
chromium-rel-mac11-pro
chromium-rel-mac12
chromium-rel-mac12-mini-8gb
chromium-rel-win10
chromium-rel-win7-dual
chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-intel
chromium-rel-win7-gpu-nvidia
chromium-rel-win7-x64-dual
chromium-rel-win8-dual
win-high-dpi

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

This seems quite likely. Do you expect us to do anything about this? native heap profiling provides:

1) Much higher reliability metrics for memory usage [significantly lower noise]
2) Better ability to debug regressions.

This bug is mostly about the regression of benchmark duration. This is particular important if we want to keep the benchmark cycle fast, but if the heap profiling does help with (1) & (2), I think the trade off worths it.

For this bug, all I want is verifying that the jump on the benchmark duration is due to native heap profiling and not something else.

No, the regression range doesn't match up.

https://chromium.googlesource.com/chromium/src/+log/808540a1356b6cc5bebaf0eabc15a333823985df%5E..35c710a8c0271ada62f0a4096412ac521041ce65?pretty=fuller

Reassign to you for triaging investigating this (since you are listed as this benchmark's owner).

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

Hi dskiba@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 : dskiba
  Commit : d4a5e98235da0cc8c4fb1ae2f67826b0b480ce4c
  Date   : Mon Jun 19 21:10:15 2017
  Subject: [tracing] Switch to new heap dump format.

Bisect Details
  Configuration: winx64_high_dpi_perf_bisect
  Benchmark    : memory.desktop
  Metric       : benchmark_duration/benchmark_duration
  Change       : 110.56% | 5.007797222 -> 10.5443194456

Revision             Result                   N
chromium@480554      5.0078 +- 0.225949       6      good
chromium@480573      5.07019 +- 0.371097      6      good
chromium@480578      4.96399 +- 0.250694      6      good
chromium@480579      5.11791 +- 0.212178      6      good
chromium@480580      10.4529 +- 0.160198      6      bad       <--
chromium@480581      10.4491 +- 0.278276      6      bad
chromium@480583      10.3535 +- 0.454461      6      bad
chromium@480592      10.3818 +- 0.425868      6      bad
chromium@480629      10.5012 +- 0.327179      6      bad
chromium@480703      10.5443 +- 0.291315      6      bad

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 memory.desktop

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8976131952630477376

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5262439446216704


| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Speed>Bisection.  Thank you!