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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICglraCswoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICglonYrwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICglvagrgoM


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

chromium-rel-mac-retina
chromium-rel-mac10
linux-release

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

===== BISECT JOB RESULTS =====
Status: failed


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N  Good?
chromium@409796  4.0431   0.0280426  5  good
chromium@409804  4.03511  0.109318   8  good
chromium@409805  4.06369  0.0826172  5  good
chromium@409806  3.60221  0.169349   5  bad
chromium@409808  3.75538  0.0575883  8  bad
chromium@409811  3.72238  0.0346838  5  bad

Bisect job ran on: mac_retina_perf_bisect
Bug ID: 635513

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests blink_perf.parser
Test Metric: tiny-innerHTML/tiny-innerHTML
Relative Change: 7.93%
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_retina_perf_bisect/builds/1548
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9004891750153126880


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5900717773029376

| 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 Tests>AutoBisect.  Thank you!

alexclarke: I'm filing a separate bug on the bisect output, but it looks like this is https://codereview.chromium.org/2209283002

Filed bug on confusing bisect output here: https://github.com/catapult-project/catapult/issues/2626

Looks like my patch may have regressed the blink_perf.parser benchmark. I assume it must be some kind of micro benchmark since I guess I'd be pretty surprised if it really made a significant real-world difference.

Please advise: does this regression matter, if so do you have any ideas for how to make this functionality faster? 

Thanks!

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

===== BISECT JOB RESULTS =====
Status: failed


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N  Good?
chromium@409796  4.0431   0.0280426  5  good
chromium@409804  4.03511  0.109318   8  good
chromium@409805  4.06369  0.0826172  5  good
chromium@409806  3.60221  0.169349   5  bad
chromium@409808  3.75538  0.0575883  8  bad
chromium@409811  3.72238  0.0346838  5  bad

Bisect job ran on: mac_retina_perf_bisect
Bug ID: 635513

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests blink_perf.parser
Test Metric: tiny-innerHTML/tiny-innerHTML
Relative Change: 7.93%
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_retina_perf_bisect/builds/1548
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9004891750153126880


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5900717773029376

| 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 Tests>AutoBisect.  Thank you!

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

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

Hi alexclarke@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Fix HTMLDocumentParser::stopBackgroundParser crash
Author  : alexclarke
Commit description:
  
HTMLDocumentParser::stopBackgroundParser was getting called from
HTMLDocumentParser::~HTMLDocumentParser, this is a problem because it
assumes document() is valid.  That's not always the case since both
HTMLDocumentParser and Document are on the oilpan heap and it's not
allowed to dereference an object like that in the destructor.

As a workaround I've added a pre-finalizer.  This fixes the crash
described in the bug.

BUG= 634244 

Review-Url: https://codereview.chromium.org/2209283002
Cr-Commit-Position: refs/heads/master@{#409806}
Commit  : 61c5d52a6f5366abfec4474bec4b0dd5965abf22
Date    : Thu Aug 04 16:38:33 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N  Good?
chromium@409796  4.11527  0.0827068  5  good
chromium@409804  4.02669  0.0582061  5  good
chromium@409805  3.99788  0.115892   5  good
chromium@409806  3.76092  0.101002   5  bad    <--
chromium@409808  3.69138  0.0428249  5  bad
chromium@409811  3.70109  0.0630295  5  bad

Bisect job ran on: mac_retina_perf_bisect
Bug ID: 635513

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests blink_perf.parser
Test Metric: tiny-innerHTML/tiny-innerHTML
Relative Change: 10.06%
Score: 99.5

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_retina_perf_bisect/builds/1551
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9004891750153126880


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5900717773029376

| 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 Tests>AutoBisect.  Thank you!

Let's WONTFIX this.

innerHTML performance does matter, so the micro-benchmark is relevant.
However, this CL is not regressing innerHTML parsing performance itself but d-tor cost of HTMLDocumentParser, which shouldn't be an issue on real-world use cases.