Issue metadata
Sign in to add a comment
|
AverageCPU.BrowserProcess more than doubles on the Mac |
||||||||||||||||||||||
Issue descriptionChrome Version: between 56.0.2905.0 and 56.0.2906.0 UMA shows a > 100% jump in PerformanceMonitor.AverageCPU.BrowserProcess at the 50th percentile between 56.0.2905.0 and 56.0.2907.0 (Canary) and between 56.0.2902.0 and 56.0.2906.0 (Dev). UMA also shows that the regression occur on the Mac but not on Windows. When I started looking through the Dev changelog I found: Ship WebBluetooth out of origin trial https://codereview.chromium.org/2437943002/ which enables WebBluetooth by default on the Mac and ChromeOS. This cl does not appear in the Canary changelog but there are a number of other Bluetooth cls present - it could be that something enabled by those cls is causing the problem. juncai@ - can you tell me how WebBluetooth is implemented on the Mac? At one time device characteristic changes were discovered using polling. Is that still the case? I tried https://chromium.googlesource.com/chromium/src/+log/56.0.2905.0..56.0.2906.0?pretty=fuller&n=10000 https://uma.googleplex.com/p/chrome/timeline_v2/?sid=ee50da20063f2a8adf36a6e88897d956
,
Dec 15 2016
+ben for fyi: seems like a speed-releasing-relevant bug
,
Dec 15 2016
Any chance this is related to issue 673021?
,
Dec 15 2016
That change landed in 56.0.2902.0, so it certainly lines up with the dev regression range. Looking at a blow-up of AverageCPU.BrowserProcess, there's a slight regression when 2902 lands (C5 in the graph). That uptick continues for a few more versions and then takes off with 2906/2907, so it seems like something else is at play, but maybe not.
,
Dec 15 2016
Web Bluetooth: I'll verify this empirically, but it shouldn't be the cause because we lazy load the systems only for sites that use the API. So, there should only be Web Bluetooth related impacts for a tiny fraction of users that have been trying demo pages.
,
Dec 15 2016
Regarding the device characteristic changes, a web bluetooth client is registered with the web bluetooth service, and once there is device characteristic change, the service will notify the client, so I don't think it is done by polling now.
,
Dec 15 2016
Can you point me at the code that discovers the characteristic change?
,
Dec 15 2016
Thank you. I see that on the Mac the code is calling -[CBPeripheral setNotifyValue:forCharacteristic:] to register for characteristic changes, which is good.
,
Dec 15 2016
Web Bluetooth: The Bluetooth adapter is brought up at browser start. (So I was wrong in #5). However, this was true before this regression (56.0.2902.0). Exiting origin trial did not change this behavior.
,
Dec 16 2016
Could https://bugs.chromium.org/p/chromium/issues/detail?id=461181 be related to that issue?
,
Dec 16 2016
It could be. It depends on whether a BluetoothAdapter is created lazily (only for sites that use the API) or if there's always one running. scheib@ - do you know the answer to that? Even if it's created lazily we will want to measure the energy impact of this 500ms polling, but that can happen in a separate bug. Note to myself: device/bluetooth/bluetooth_adapter_mac.mm
,
Dec 16 2016
The BluetoothAdapter is constructed when Chrome launches, and it was already doing so before this regression. Transitioning Web Bluetooth from origin trial to on by default did not change this. Issue 461181 (Investigate jank of BluetoothAdapterMac::PollAdapter) had all related patches land before this regression. We don't have a way to bisect this metric, because it's UMA, correct? Can we find a related perf metric that runs on bots that can be correlated and bisected?
,
Dec 16 2016
Meanwhile. Issue 673021 (DelayBasedBeginFrameSource infinite loop for extensions) has moved forward with fixes in the last 24 hours. erikchen@, shrike@, do we have reason to believe those are the root cause?
,
Dec 16 2016
Re: the polling, I see it's been present for some time, however I'm assuming no work was done to evaluate the energy impact. We need to do this (I will pursue). Re: Issue 673021, that change landed yesterday. There's not really any action to take in this bug until we give it some air time out in the wild and then recheck PerformanceMonitor.AverageCPU.BrowserProcess.
,
Dec 16 2016
Re: Bluetooth polling: To be clear we're discussing BluetoothAdapterMac::PollAdapter, right? https://cs.chromium.org/search/?q=f:bluetooth_adapter_mac.mm+kPollIntervalMs+PollAdapter&sq=package:chromium&type=cs and issue 461181 . Or is there additional polling? Presuming not, I think we can continue polling discussion on issue 461181 .
,
Dec 16 2016
Yes, the polling in BluetoothAdapterMac::PollAdapter is what I'm referring to, and I agree we can discuss over in that issue.
,
Dec 16 2016
Next step is to check UMA stats, hoping that Issue 673021 fixes this issue. Assigning to myself.
,
Jan 3 2017
shrike@, Could you please update on this stable blocker.
,
Jan 3 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by shrike@chromium.org
, Dec 15 2016