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

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


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

android-webview-nexus6

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

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

Remove PausableTimer from DOMWindowEventQueue by hajimehoshi@chromium.org
https://chromium.googlesource.com/chromium/src/+/cb5d04f327ea4807d4db8dbf2750368673618361
27.73 → 32.13 (+4.4)

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

I understood the reason: Before the CL, events were queued to a hash set and all the queued events were dispatched when a timer was fired. After the CL, each event was queued as a task and dispatched one by one.

I'd like to mark this issue 'wontfix' since this is a kind of WAI.

+jsbell (an owner of indexeddb part), what do you think?

Should we file a bug on general scheduling performance optimisations and block this on that? Agreed that no immediate action is necessary.

Another similar issue is https://bugs.chromium.org/p/chromium/issues/detail?id=849045, but this is a little different thing since I'm still not sure the culprit of 849045.

> Should we file a bug on general scheduling performance optimisations and block this on that?

The number of similar problems are two including this as far as I know, and as I commented, the causes seem different. Then I'd like to leave them as they are.