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

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


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

android-nexus5
android-one
chromium-rel-mac11-air
chromium-rel-mac11-pro
chromium-rel-mac12
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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16dde03d840000

📍 Found significant differences after each of 2 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/16dde03d840000

Introduce slot-in-flat-tree behind experimental flag. by futhark@chromium.org
https://chromium.googlesource.com/chromium/src/+/2faa2b6b25dc948985640efbb5f4b6b5c38efbcb

Rename GetWebTaskRunner() to GetTaskRunner() in modules/. by yutak@chromium.org
https://chromium.googlesource.com/chromium/src/+/a5eeff12b16a3506960fbd698d3c2aef444b2d4e

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Actually, I think this is due to my CL changing the return value type to
scoped_refptr<>, adding extra ref churn.

I'm going to revert the return type to a plain pointer, which should fix this.

Well, I would say my CL and futhark's change are equally suspicious -- I'm going
to land my fix anyway to prove or disprove my theory.

futhark@, you may want to research on your CL in parallel.

After I think about this, I'm more convinced that my CL was NOT the culprit,
so I'm not landing the speculative fix for my CL.

futhark, I'm re-assigning you since yours is more likely to be causing the
regression -- sorry for the mess-up on my side.

I've confirmed that it's the slot-in-flat-tree enabled in experimental that's causing this. I've run the perf-test through callgrind. The test is a wide and deep tree of shadow dom v1 hosts which all contains a slot. With slots in the flat tree, we do more work for slot elements. We store ComputedStyle for them as we would for other display:contents elements in order to inherit down to assigned nodes which means we create more element rare data as well as storing the ComputedStyle.

Callgrind shows there's generally more work done for slots both for style recalc and layout tree building in this case, but I haven't identified anything suspicious or unexpected, really.

Running this test in WebKit MiniBrowser which includes slot elements in the flat tree shows they're running the large+deep test at ~6800ms while my Content Shell is at ~2700ms running locally.

SGTM for WontFix. Thank you for the investigation.