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

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


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

linux-perf

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

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1436e870140000

The regression seems like real to me at a glance and happening on Linux, Mac, Windows at least, but afaict, there seems no bindings change in the range.
https://chromium.googlesource.com/chromium/src/+log/f8903aaa563be628c2278a4cd55e879d603ef722%5E..0dedb2cb2cc9ddf26cd566c557cfff93a694c9dd?pretty=fuller&n=1000

Is it possible that the perf results are affected by V8 change?
https://chromium.googlesource.com/v8/v8/+log/483d8219fb702e68063cb1aba491b23e3e4c617d..62e154db22beb234b200d1cb93ba043f4ca1fadc

In the test, we're constructing a long string, and I'm not sure if the cost is really negligible or observable.  Are we observing "string construction time" or "serialization time"?

I'm not really sure if this is a real regression or not.  Your insights are welcome.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1582b2f3e40000

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

[heap] Reland improvements for embedder tracing by mlippautz@chromium.org
https://chromium.googlesource.com/v8/v8/+/c32a378f4806236a10c563a1fbf576222dfd695d
structured-clone-long-string-serialize: 375.9 → 413.4 (+37.52)

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

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

This regression seems to be introduced by the V8 roll, and it's dup with another issue 909788.