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

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


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

chromium-rel-mac11
chromium-rel-mac12-mini-8gb

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14bf63e2840000

📍 Found a significant difference after 1 commit.
https://pinpoint.chromeperf.appspot.com/job/14bf63e2840000

Eliminate blink::BlobDataItem.
By mek@chromium.org · Thu Jan 18 21:42:40 2018
chromium @ db1b4e28db01ef1f2fa9f138a426165f636f07cc

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

Not sure why this would be causing a regression, but I think the difference is small enough not to worry about.

I don't understand this metric so I cannot judge the significance of this regression. I will leave it up to the benchmark owner (dmurph@) to re-open if they disagree.

I tried to look into this a bit deeper since the new code should be faster/do less allocations, and did some profiling. Hard to get any meaningful data though since these tests really are doing so little work (creating blobs of 2 bytes) that any difference is dwarfed by the fixed overhead of creating/reading blobs.
So not sure why these tests seem to in fact have gotten consistently slower after my change, but I'm fairly confident it's nothing to worry about (and all the mojo blob changes together still made these tests way faster than they ever were, but that's mostly on the loading side, not the creation side).