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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg4Z616woM


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

chromium-rel-mac11

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/9001970861515320496

===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Delay WebUSB initialization until after browser startup.
Author  : reillyg
Commit description:
  
Initializing the WebUSB device detector module causes the USB service to
be initialized and enumerate all USB device connected to the system.
This can cause unnecessary delay during browser startup. The purpose of
this module is to detect devices connected after Chrome starts to
display a notification so it doesn't matter if it is initialized after
first page load.

An UMA histogram for the time spent initializing the detector is also
added to aid further investigation of this issue.

BUG= 642107 

Review-Url: https://codereview.chromium.org/2295023002
Cr-Commit-Position: refs/heads/master@{#415971}
Commit  : 478a62181383d2cc7fa545ee6a7a91ab34fec477
Date    : Thu Sep 01 16:45:35 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev   N  Good?
chromium@415944  22.5709  0.127725  8  good
chromium@415961  22.5897  0.194483  8  good
chromium@415969  22.6379  0.130187  8  good
chromium@415970  22.6329  0.104595  8  good
chromium@415971  24.4334  2.06017   5  bad    <--
chromium@415973  25.7126  2.31703   8  bad
chromium@415977  26.1973  2.20123   8  bad
chromium@416009  25.7495  2.2683    8  bad

Bisect job ran on: mac_10_11_perf_bisect
Bug ID: 645583

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --also-run-disabled-tests smoothness.gpu_rasterization.tough_path_rendering_cases
Test Metric: frame_times/frame_times
Relative Change: 17.34%
Score: 80.0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_11_perf_bisect/builds/884
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9001970861515320496


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6063488416350208

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

reillyg, seems your patch caused a performance regression. Can you please investigate?

I am not familiar with this test. Can you explain what it is measuring?

I believe it's the amount of time to generate each frame. Adding test owner senorblanco to explain further.

The change above may add a one-time delay to the generating a single frame but shouldn't cause persistent slowness.

Yes, it's a graphical, frame_times test which renders many frames. It seems unlikely to have been affected by something run only once at startup. I'd re-run the bisect.

Note that only the chromium-rel-mac11 bot seems to be affected. Most other bots seem to be fine. I'm suspecting some kind of bot-specific problem.

https://chromeperf.appspot.com/report?sid=f52792ef5c6b2ee8d0178910cb375d82df387b6e2a2106a27368c1756bcdd4f9&start_rev=414667&end_rev=418253

Perf sheriff ping

What did that re-bisect turn up?

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8998513633715146144

=== Auto-CCing suspected CL author reillyg@chromium.org ===

Hi reillyg@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Delay WebUSB initialization until after browser startup.
Author  : reillyg
Commit description:
  
Initializing the WebUSB device detector module causes the USB service to
be initialized and enumerate all USB device connected to the system.
This can cause unnecessary delay during browser startup. The purpose of
this module is to detect devices connected after Chrome starts to
display a notification so it doesn't matter if it is initialized after
first page load.

An UMA histogram for the time spent initializing the detector is also
added to aid further investigation of this issue.

BUG= 642107 

Review-Url: https://codereview.chromium.org/2295023002
Cr-Commit-Position: refs/heads/master@{#415971}
Commit  : 478a62181383d2cc7fa545ee6a7a91ab34fec477
Date    : Thu Sep 01 16:45:35 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N   Good?
chromium@415944  22.5239  0.123906   8   good
chromium@415961  22.5854  0.121367   18  good
chromium@415969  22.6201  0.138009   18  good
chromium@415970  22.6443  0.0438131  5   good
chromium@415971  26.3174  1.58987    8   bad    <--
chromium@415973  26.2274  1.70492    5   bad
chromium@415977  25.4839  2.27059    18  bad
chromium@416009  26.0399  1.97674    8   bad

Bisect job ran on: mac_10_11_perf_bisect
Bug ID: 645583

Test Command: src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests smoothness.gpu_rasterization.tough_path_rendering_cases
Test Metric: frame_times/frame_times
Relative Change: 12.91%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/mac_10_11_perf_bisect/builds/966
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8998513633715146144


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5880650660315136

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

Hey reillyg, After this regression, the benchmark started getting quite noisy and it hasn't progressed since. Can you please take a look and either revert or justify this CL?

I'm working a followup CL to r415971 that should mitigate this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/20dbee333a778a90bd8966a7a5227d3cb4592e5d

commit 20dbee333a778a90bd8966a7a5227d3cb4592e5d
Author: reillyg <reillyg@chromium.org>
Date: Thu Dec 08 22:52:01 2016

Call libusb_init on the FILE thread.

On some platforms this function creates an initial enumeration of
devices which can cause jank when done on the UI thread.

BUG= 645583 

Review-Url: https://codereview.chromium.org/2557073004
Cr-Commit-Position: refs/heads/master@{#437382}

[modify] https://crrev.com/20dbee333a778a90bd8966a7a5227d3cb4592e5d/device/usb/usb_context.h
[modify] https://crrev.com/20dbee333a778a90bd8966a7a5227d3cb4592e5d/device/usb/usb_service_impl.cc
[modify] https://crrev.com/20dbee333a778a90bd8966a7a5227d3cb4592e5d/device/usb/usb_service_impl.h

It looks like the graph has gone back to its original level.