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

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


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

Win 7 Perf

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/148ba617640000

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/148ba617640000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16966ceb640000

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

Element::setAttribute() modified to accept TrustedTypes by kabusm@google.com
https://chromium.googlesource.com/chromium/src/+/bc1bd3c02b8a2fcdcb423aacbe1ca4bbdbc81b71
2.54 → 2.83 (+0.29)

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

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

kabusm + I just spent a good bit of time analyzing this, unfortunately without a clear path out:

- We can confirm the observation: The µBenchmark gets slower at the given CL.
- There does not seem to be an effect on any non-trivial benchmarks.
- After experimenting a bit, the difference stems from the change in the IDL, not from the actual logic done during Element::setAttribute.
  - That is, if we replace the body of the new netAttribute methods with only a call to the existing code, the code remains 'slow'.
  - When we change the IDL back to DOMString (or e.g. HTMLString), things are 'fast' again.

My conclusion is that we're measuring the overhead of the IDL union type with 5 members. The benchmark only uses the String member, but needs to construct the union type. A union type with only 2 members has no (or much smaller) performance impact.

That unfortunately means that I'm not seeing a super easy fix.
However, it also means that this is unlikely to have a substantial effect on 'real' code, where the logic within setAttribute would likely have to do enough work so that the union-type overhead would hopefully no longer matter.