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

Issue 44494 link

Starred by 23 users

Issue metadata

Status: Fixed
Owner:
Closed: May 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Renderers idle at 1.5% cpu on mac

Project Member Reported by thakis@chromium.org, May 18 2010

Issue description

Chrome Version       : 6.0.401.1 dev, current latest waterfall

What steps will reproduce the problem?
1. Open two tabs, one with google.com, one with the NTP
2. Open Activity Monitor (or chrome's task manager)
3. Wait a bit

What is the expected result?

%cpu used by the renderers should be close to 0. Instead, they hover around 1.5% cpu all the 
time. Shark says the time is mostly spent doing IPC.

build-bisect gives these CLs as possible culprits: 
http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?
url=/trunk/src&range=46560:46596 . http://src.chromium.org/viewvc/chrome?
view=rev&revision=46567 looks like the most likely culprit to me.

For some reason, I can't reproduce this on windows and linux.

Marking this as Area-Internals for now.
 
Note that 46567 was later reverted at 46642, then fixed and checked in again later as 
46916 - you might want to see if the problem was happening between 46642 and 46916 to 
see if this change was related or not.

Comment 2 by thakis@chromium.org, May 18 2010

Happens in 46666 as well, which means it must be something else.

Comment 3 by thakis@chromium.org, May 18 2010

There's http://src.chromium.org/viewvc/chrome?view=rev&revision=46573 (WebKit roll 58855:58879), but 
looking through the webkit revisions in that range doesn't show anything that's suspicious at first glance.

Comment 4 by jrg@chromium.org, May 19 2010

Labels: Regression
Status: Assigned
Please reconfirm in QA kthxbye
 Issue 44255  has been merged into this issue.

Comment 6 Deleted

Status: Untriaged
Confirmed using TOT build 6.0.411.0 (r47758).
We don't see this in 5.0.375.55 (r47796) beta.

Comment 8 by krisr@chromium.org, May 21 2010

Labels: Performance

Comment 9 by thakis@chromium.org, May 21 2010

Activity Monitor on my macbook suggests the idle utilization is more like an average of 4% or more.

On the 5.0.375.55 beta release I see Renderer processes idle at an average of perhaps 0.3%, definitely not 
zero.  If all other windows fully obscured or iconified (i.e. with only one tab showing) then I would think the 
renderers should be at zero if there's no javascript running and no scrolling happening.

I have one tab that runs at about 6% (and that's with the flash plugin disabled).  I can't explain it, other than 
perhaps bad javascript.  When I open the JS console on that page, it jumps to 80% or more.  It's this one:

    http://newenergyandfuel.com/http:/newenergyandfuel/com/category/fusion/

It looks like r46588 is to blame ( http://codereview.chromium.org/1989002 ). I manually synced & built to 
several revisions in the regression window, and the bad behavior is present in r46588 but not in r46487.
The reason this happens on mac is this piece of code from tab_contents_view_mac.mm:

void TabContentsViewMac::RenderViewCreated(RenderViewHost* host) {
  // We want updates whenever the intrinsic width of the webpage
  // changes. Put the RenderView into that mode.
  int routing_id = host->routing_id();
  host->Send(new ViewMsg_EnablePreferredSizeChangedMode(routing_id));
}

The other platforms don't call this from their tab contents, and r46588 removed the check that didn't install a 
10ms permanent timer in the renderer for normal web tab contents ( 
http://codereview.chromium.org/1989002/diff/1/8 ).

I guess options are
1.) reintroducing that check (dunno if that breaks app mode)
2.) adding more parameters to the ipc message to let clients specify if they need polling
3.) removing the call from tab contents mac.

mpcomplete or jcivelli might know if 1 is safe, that seems easiest. Pink added the mac-specific code in 
http://codereview.chromium.org/115138 , but that doesn't list a bug, so I'm not sure what it's good for (back 
then without polling). 

If 1 doesn't fly, both 2 and 3 seem not optimal. (In that case, it's probably best to add a new view mode for app 
mode windows and then do 1 with that?)
The polling stuff was introduced in http://codereview.chromium.org/556058 , which is somewhat short on 
details as well. It seems like something could be fixed in webkit to remove the polling in all cases (aa: do you 
have a link to the webkit bug you mentioned in that review?). It also seems like it's probably ok to do 1.) with a 
new view mode for app mode windows.
Root cause is https://bugs.webkit.org/show_bug.cgi?id=32807 . Quote: "It is possible to get the content's true 
height using frame->document()->documentElement()->scrollHeight(), but there is no corresponding event for 
when this changes." The "short-term" solution was to add polling (at 100 Hz!) for that value

I filed  issue 44850  to track the chromium side of the webkit fix.

(Also related to this bug's history: http://codereview.chromium.org/400028 )
Labels: -Area-Internals -Pri-2 Area-WebKit Pri-1 Mstone-6
Status: Assigned
This needs to be addressed sooner than later.
Status: Started
Working on a bandaid fix.
Reintroducing the check (option 1 above) will break the new app launcher that needs
to know the preferred size of its contents so it can be sized correctly (and it is
not an extension).

It seems to me like having an extra param in the IPC request to specify whether to
poll or not would be a good solution.

Sorry for introducing this bug :-(


Labels: -OS-Mac OS-All
Polling is always wrong, it should be removed ASAP.  If the app launcher (or any other feature) depends on it then 
it should be fixed in some other way that is not horrible.

Based on the rev, this is probably in 375 - right?
Status: Fixed
Band-aid committed as http://src.chromium.org/viewvc/chrome?view=rev&revision=48056 . As I said above, 
 issue 44850  is about fixing the polling.
re comment 19: 375 was branched at 44202, so this isn't in the beta.

Comment 22 by aa@chromium.org, May 24 2010

Fast work. FWIW, I think this fix is a good solution.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=48056 

------------------------------------------------------------------------
r48056 | thakis@chromium.org | 2010-05-24 11:11:39 -0700 (Mon, 24 May 2010) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/extensions/extension_host.cc?r1=48056&r2=48055
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/notifications/balloon_host.cc?r1=48056&r2=48055
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_view_host.cc?r1=48056&r2=48055
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_view_host.h?r1=48056&r2=48055
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents.cc?r1=48056&r2=48055
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/tab_contents_view_mac.mm?r1=48056&r2=48055
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/render_messages.h?r1=48056&r2=48055
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/render_messages_internal.h?r1=48056&r2=48055
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/render_view.cc?r1=48056&r2=48055
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/render_view.h?r1=48056&r2=48055

Mac: Fix renderer idle cpu usage regression.

Since polling is required only for the preferred height and mac only needs preferred width, add a flag that specifies if the client is interested in width and/or height.

This is a band-aid, the Real Fix is tracked in 44850.

BUG= 44494 
TEST=Open chrome's task manager. Idle renderer processes should take close to 0 %cpu instead of ~1.5 before.

Review URL: http://codereview.chromium.org/2145002
------------------------------------------------------------------------

It's a good bandaid, but it is definitely not a solution.
This still is a problem.
Chrome uses (many tabs and windows) around 40% cpu idle here. No flash.
Also keeps consuming more and more memory (over 6GB real memory)

Going back to safari, as my whole computer drags..
Maybe it's the videocard..

I've asked many many times how I can help by providing stacktraces / memdumps.. But no help from google
I'm running a macbook with a gma950
cpu time is mostly kernel_time. and temp goes up to 85 celcius, and fans turn on.
Labels: -Mstone-6
Are you sure it's a normal renderer? Maybe an extension has gone haywire. What does the task manager say?

40% idle with no flash is nuts. What page are you on when you see this? Does it have a lot of html5/css animations? We need specifics.

Comment 28 by thakis@google.com, Jan 18 2011

We also need a new bug; the problem this one's fixed.

Comment 29 by dfoo...@gmail.com, Feb 3 2011

Is there a new bug for this?  I still have the issue.  They idle at 3%. 

Comment 30 by thakis@google.com, Feb 3 2011

Do you have any extensions installed? Does it go away if you temporarily disable all your extensions at chrome://extensions?

Comment 31 by dfoo...@gmail.com, Feb 3 2011

I don't have any extensions installed.

Comment 32 by thakis@google.com, Feb 3 2011

Then open a new issue please. This one was visible on all machines, while yours is not visible e.g. on mine – so it's a different bug.
Labels: -Regression bulkmove Type-Regression
Chrome Version       : 6.0.401.1 dev, current latest waterfall

What steps will reproduce the problem?
1. Open two tabs, one with google.com, one with the NTP
2. Open Activity Monitor (or chrome's task manager)
3. Wait a bit

What is the expected result?

%cpu used by the renderers should be close to 0. Instead, they hover around 1.5% cpu all the 
time. Shark says the time is mostly spent doing IPC.

build-bisect gives these CLs as possible culprits: 
http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?
url=/trunk/src&range=46560:46596 . http://src.chromium.org/viewvc/chrome?
view=rev&revision=46567 looks like the most likely culprit to me.

For some reason, I can't reproduce this on windows and linux.

Marking this as Area-Internals for now.
Labels: -Performance Stability-Performance
Chrome Version       : 6.0.401.1 dev, current latest waterfall

What steps will reproduce the problem?
1. Open two tabs, one with google.com, one with the NTP
2. Open Activity Monitor (or chrome's task manager)
3. Wait a bit

What is the expected result?

%cpu used by the renderers should be close to 0. Instead, they hover around 1.5% cpu all the 
time. Shark says the time is mostly spent doing IPC.

build-bisect gives these CLs as possible culprits: 
http://build.chromium.org/buildbot/perf/dashboard/ui/changelog.html?
url=/trunk/src&range=46560:46596 . http://src.chromium.org/viewvc/chrome?
view=rev&revision=46567 looks like the most likely culprit to me.

For some reason, I can't reproduce this on windows and linux.

Marking this as Area-Internals for now.
Project Member

Comment 35 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 36 by bugdroid1@chromium.org, Mar 9 2013

Labels: -Area-WebKit -Type-Regression -Stability-Performance Cr-Content Type-Bug-Regression Performance
Project Member

Comment 37 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Sign in to add a comment