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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtJC5pAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDglOWXvwsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDglIu67AoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDglJ250goM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtISw_wgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg1Nfa4AoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg1L6dqwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtKSQpwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtOC8ugoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDglMHZggsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg1NSr3gkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg1N7MoQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg1LLX_wsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDg1LzI5AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgtOr6qAoM


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

android-nexus5
android-nexus6
android-nexus7v2
android-webview-nexus6
chromium-rel-mac11
chromium-rel-mac12
chromium-rel-mac12-mini-8gb
chromium-rel-win10
chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-intel
chromium-rel-win7-gpu-nvidia
chromium-rel-win8-dual

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

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

Hi pdr@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 : pdr
  Commit : ce1b788de6382f8c3725efe1fb14e9d4c639b5ab
  Date   : Thu Mar 09 04:36:32 2017
  Subject: Heap allocate PrePaintTreeWalk context object

Bisect Details
  Configuration: mac_10_11_perf_bisect
  Benchmark    : blink_perf.paint
  Metric       : complex-content-slow-scroll/complex-content-slow-scroll
  Change       : 56.41% | 152.72325 -> 238.879166667

Revision             Result                  N
chromium@455646      152.723 +- 5.14132      6      good
chromium@455661      147.37 +- 4.6609        6      good
chromium@455665      146.507 +- 6.32714      6      good
chromium@455667      148.366 +- 2.98127      6      good
chromium@455668      217.438 +- 17.5952      6      bad       <--
chromium@455669      222.251 +- 18.0772      6      bad
chromium@455676      231.552 +- 27.143       6      bad
chromium@455706      238.879 +- 16.6375      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 blink_perf.paint

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

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


| 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!

This is real and confirms Xianzhu's suspicions about the perf impact. I think we will need to take another approach.

USING_FAST_MALLOC(PrePaintTreeWalkContext)?

Or Vector<PaintPropertyTreeBuilderContext> m_treeBuilderContexts in PrePaintTreeWalk?

Also, looks like PrePaintTreeWalkContext stores a heap-allocated PaintPropertyTreeBuilderContext.  If its lifetime is tied to PrePaintTreeWalkContext, can we store it inline instead (and trade the PaintPropertyTreeBuilderContext allocation for the PrePaintTreeWalkContext allocation)?

We can't use a vector because vector re-allocates as it grows, and our context keeps raw pointers to the parent context. Or, we have to change that parent pointer behavior. I actually like changing that because it's confusing. Will investigate one or all of these approaches.

Re #8 and #9:

Now we allocate PaintPropertyTreeBuilderContext instead of PrePaintTreeWalkContext in heap after https://codereview.chromium.org/2741833005.

As PaintPropertyTreeBuilderContext doesn't have pointer to parent context, can we use vector for it (after trying USING_FAST_MALLOC)?

How often is the context updated?  Do we expect all/most nodes to mutate it?

If not, another idea would be to make the allocation lazy (CoW context).

Yes, I think we can share one PaintPropertyTreeWalkContext among multiple PrePaintTreeWalks. We may need to separate out current.paintOffset which is updated much more frequently than other fields.

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

Just landed https://codereview.chromium.org/2744243010 which should improve these graphs. I'm going to hold off on marking as fixed though.

Teh graphs are happy