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

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


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

android-nexus5

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/139248dbc40000

📍 Found significant differences after each of 3 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/139248dbc40000

Report video group ID in low-level device enumerations and notifications. by guidou@chromium.org
https://chromium.googlesource.com/chromium/src/+/2aa26b30517b6a33ba7edf8f2d17353c919de855

[oilpan] Enable incremental marking buildflag by mlippautz@chromium.org
https://chromium.googlesource.com/chromium/src/+/bd9ac13acc9d99a4f192b2734613545c187a319c

Delete protocol handlers with site settings by dullweber@chromium.org
https://chromium.googlesource.com/chromium/src/+/5decc53ab1b02778a8e05400efafd45424132a28

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

Pinpoint suggests that the first 2 CLs cause some regressions.

The oilpan CL has been reverted (but will reland) because of other reasons. Some parts have recovered but there are definitely regressions left. 

Where can one see the code that this test runs?
The changes in r555697 run only if there are device enumerations (e.g., enumerateDevices() or getUserMedia() require device enumerations). If there are device enumerations, they should be slightly slower than before r555697.
If the test does not call call a function that performs enumerations, I don't know how it can cause a performance regression.

I don't think the protocol handler CL is related to this regression. I'm not sure about the other CLs. Please reassign if I'm wrong

Test seems very noisy, CLs look completely unrelated