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

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


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

Android Nexus5 Perf

blink_perf.shadow_dom - Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/134d5be0140000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/134d5be0140000

[FCP++] Enable FCP++ metrics via finch experiment by maxlg@chromium.org
https://chromium.googlesource.com/chromium/src/+/4e243fc4a328acee8354c73e7c9df2facac9f3f7
v1-small-deep-distribution: 145.8 → 180 (+34.21)

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

Benchmark documentation link:
  https://bit.ly/blink-perf-benchmarks

+Hayato, I am trying to figure out how does shadow_dom related to FCP++. I can see FCP++ can cause regression in memory cost and pre-paint tree walk in layout. Does this benchmark regress because layout regress? If it's the case then I can just focus on fixing the layout regression.

> Does this benchmark regress because layout regress?

TL;DR; This shouldn't. The regressions looks strange to me. We need to figure out why this has a regression.


v1-small-deep-distribution.html has a regression, which measures the cost of runHostChildrenMutationThenGetDistribution(host, loop).

runHostChildrenMutationThenGetDistribution is defined here:

https://cs.chromium.org/chromium/src/third_party/blink/perf_tests/shadow_dom/v1-common.js?q=runHostChildrenMutationThenGetDistribution&sq=package:chromium&g=0&l=70

AFAIK, runHostChildrenMutationThenGetDistribution doesn't cause any layout;  slot.assignedNodes({ flatten: true }) shouldn't cause any layout.

My feature also adds cost in Pre-paint tree walk and DOM node detachment. Maybe it's related?

AFAIK, this perf test doesn't measure the cost of node detachment because layout doesn't happen in run(), I believe.

I'm not sure what pre-paint tree walk means. If you can share more context, I might give you more insights.