New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 797516 link

Starred by 4 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

Chrome uses 75% more CPU on airma.sh html game than Safari (and 18% more than Firefox)

Project Member Reported by esprehn@chromium.org, Dec 24 2017

Issue description

Google Chrome	65.0.3302.0 (Official Build) canary (64-bit)
Revision	ed06b93000c86b85c098703b0763862e0ff9a699-refs/heads/master@{#526108}
OS	Mac OS X 10.12.8
JavaScript	V8 6.5.102

This is on a 2017 15" Touchbar Macbook Pro.

1. Load https://airma.sh
1. Wait for the loading screen to show the spinning planes.

The below numbers are from watching the spinning planes on the login screen. You can also show the difference by playing the game.

== Chrome 65.0.3302.0 (Official Build) canary (64-bit)
Renderer 14.5%
Browser 10.7%
GPU Process 9.5%
WindowServer 10.6%

14.5+10.7+9.5+10.6 => 45.3%

== Safari 11.0.2
Renderer 10.4%
Browser 0.0%
WindowServer 15.5%

10.4+15.5 => 25.9%

== Firefox 57.0 (Quantum)
Renderer 16.0%
Browser 10.3%
WindowServer 12.2%

16.0+10.3+12.2 => 38.5%

This game is a really amazing HTML5 experience and runs great in all browsers, unfortunately it also seems to show Chrome uses considerably more CPU and power (as reported by energy monitor) than other browsers for gaming.

 
trace_airmash.json.gz
5.8 MB Download

Comment 1 by kbr@chromium.org, Dec 24 2017

Cc: sunn...@chromium.org piman@chromium.org
Components: Internals>GPU>Internals
This may be inherent in Chrome's multi-process and GPU sandboxing architecture. Strictly more work is done when remoting graphics commands from the renderer process to the GPU process than in single-process browsers, but the security properties of Chrome's architecture are better.

We should grab CPU profiles of the browser, renderer and GPU processes while running this game and see if there are areas to optimize.

Comment 2 by piman@chromium.org, Jan 9 2018

Labels: Performance-Power
Status: Available (was: Untriaged)

Comment 3 by shrike@chromium.org, Jan 17 2018

Cc: kbr@chromium.org
Attaching an Instruments 8.3.3 trace.

The attached screenshots show one of the usual suspects: CPU in the main thread used to unmarshall mojo parameters, destroy mojo messages, etc.; 27% of CPU consumed by the IOThread, which is only servicing mojo messages (i.e. no mojo messages, no IOThread CPU consumption).

> This may be inherent in Chrome's multi-process and GPU sandboxing architecture. Strictly more work is done when remoting graphics commands from the renderer process to the GPU process than in single-process browsers, but the security properties of Chrome's architecture are better.

kbr@ - have you seen this doc:

https://docs.google.com/document/d/1Ij2U31v3jq7X-4wx6Wtjan6c5GgNJUsZE6GRJZvISK0/edit?usp=sharing

ChromiumBrowserProcess65.0.3316.0.trace.zip
856 KB Download
Screen Shot 2018-01-17 at 9.39.24 AM.png
318 KB View Download
Screen Shot 2018-01-17 at 9.39.44 AM.png
143 KB View Download

Comment 4 by kbr@chromium.org, Jan 18 2018

shrike@: no, hadn't seen it. Good and interesting writeup.

Project Member

Comment 5 by sheriffbot@chromium.org, Jan 18 (4 days ago)

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 6 by kbr@chromium.org, Jan 18 (4 days ago)

Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)

Sign in to add a comment