Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 10 users
Status: Fixed
Owner:
Email to this user bounced
Closed: Oct 2008
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
TRACKING: Chrome does not implement the Webkit 10ms setTimeout clamp.
Reported by mikebel...@gmail.com, Sep 3 2008 Back to list
Product Version      : 0.2.149.27 (1583)

Some have noticed that Chrome does not implement the 10ms setTimeout clamp.  
This is particularly noticeable when you run this test:
    http://ejohn.org/blog/analyzing-timer-performance/

A few notes:
A setTimeout clamp can help avoid browser un-responsiveness for some 
browsers.  Some browsers may be unable to service UI events if the JS code 
is allowed to spin.  Chrome is less vulnerable to this due to separation of 
browser and renderer.

A setTimeout clamp is like the old PC's "Turbo button" to change it from 
66MHz to 33MHz.  This button was provided for compatibility with legacy 
apps that were hard coded to render based on the speed of the clock.  Some 
websites may depend on the 10ms clamp in order to paint properly; however 
this comes at the expense of any other applications which want a faster 
clock.

This bug is for tracking any websites which have CPU spinning due to 
Chrome's fast timers.  We'd like to converge on a common answer for both 
webkit and chrome timer behavior if possible.


 
Comment 1 by ojan@chromium.org, Sep 9 2008
Labels: -Area-Unknown Area-WebKit
Status: Untriaged
 Bug 1953  points to the following sites saying they use a lot of CPU because of this:
http://www.bobkush.com/scripts/slideinmenu.htm
http://www.dynamicdrive.com/dynamicindex1/staticmenu3.htm 

I checked into the scripts at bobkush.com and dynamicdrive.com.  Both are basically 
the same script.

The easy fix is to change the setTimeout() to a larger value; using setTimeout(0) is 
not necessary.  A better fix is to not use setTimeout and instead use the body 
onScroll event (works on FF, Webkit, IE).  This has two benefits:  First, it fixes 
the CPU issue, but secondarily (for Chrome) it removes the flicker which is pretty 
nasty when using either form of setTimeout().

Tests:
  http://www.belshe.com/test/menu-setTimeout.html
  http://www.belshe.com/test/menu-onScroll.html

One of the Gecko developers kindly passed me this link to one of their bug reports where there are a number of 
pages that show problems with not clamping (follow the duplicates for more links):
   https://bugzilla.mozilla.org/show_bug.cgi?id=123273
Ian - thanks for the reference.  I checked all URLs in the bug you mention, here is a 
summary:
  1) The dynamic drive script is the same one already referenced in this bug.
  2) http://www.attws.com/mobileinternet/  (dated 2002, invalid URL)
  3) http://www.cs.wcu.edu/~rwg/moz/123273/ (dated 2002, invalid URL)
Comment 5 Deleted
Comment 6 by ddan...@gmail.com, Sep 10 2008
I checked timers with the test mentioned above, I can see there is minimum value 
in Firefox and Safari. 10ms. If set setTimeout() to numbers below 10ms, Firefox and 
Safari will ignore it, and use 10ms. But Google Chrome has no minimum in timer. 
That means, if we use settimeout() with 1ms in recursion, Chrome try to calculate 
10 times more than other browser.

Anyhow I set time value to 10ms in dynamic drive script, then Chrome shows 3~7% 
CPU load. it looks fine, but it is still obviously higher than other browsers. (Firefox 
shows 0%.)
 
Found the first major website which has a bug due to 0ms timers:
  http://www.nytimes.com/2008/09/16/business/16paulson.html?hp

The problem is that they include the prototype.js module twice and it sets off two
setInterval timers to poll for the page being loaded.  Since it doesn't expect two
concurrently to be running, the logic for clearing the timer doesn't work.  I
notified NYT and also filed a defensive coding fix with prototype:
 
http://prototype.lighthouseapp.com/projects/8886/tickets/346-nytimes-on-safari-error-with-double-included-prototypejs
Comment 8 by jon@chromium.org, Oct 6 2008
Status: Available
Comment 9 by jon@chromium.org, Oct 14 2008
Labels: Mstone-1.0
I believe you can change this to Fixed.
Status: Fixed
After much debate, the clamp has been implemented at 4ms.

The major justification is to avoid sites like the NYTimes which were inadvertently 
looping.
Zero-second timers are useful in event listeners that run before an event, like keydown or paste (as opposed to ones that happen after, like resize), when something needs to happen after the effects of that event.  These timers should run as soon as the current event finishes up and its default behavior has executed, not after some arbitrary delay.

Clamp the delay when a timeout is set during the execution of another timer, since that's probably the main case causing unwanted busy looping.  It should not always happen.

Project Member Comment 12 by bugdroid1@chromium.org, Feb 23 2012
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=123251

------------------------------------------------------------------------
r123251 | rnk@chromium.org | Thu Feb 23 08:16:50 PST 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/tools/build/masters/master.chromium.fyi/master.cfg?r1=123251&r2=123250&pathrev=123251

Shard the drmemory full mode unit_tests runs more.

At the moment the tool's memory overhead is too high, and memory allocation
fails halfway through the first shard.  Hopefully more sharding will allow each
shard to run to completion.

R=timurrrr@chromium.org
BUG=drmemory  issue 792 
TEST=

Review URL: http://codereview.chromium.org/9452015
------------------------------------------------------------------------
Project Member Comment 13 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 14 by bugdroid1@chromium.org, Mar 11 2013
Labels: -Area-WebKit Cr-Content
Project Member Comment 15 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Project Member Comment 16 by bugdroid1@chromium.org, Jun 7 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/mojo.git/+/5e6754ba911667ba425291992e162284f142726a

commit 5e6754ba911667ba425291992e162284f142726a
Author: Viet-Trung Luu <viettrungluu@chromium.org>
Date: Tue Jun 07 20:13:47 2016

Fix the //mojo/go:application target.

* It was missing describer.go in its list of sources (so if you changed
  it, but nothing else caused the target to rebuild, you'd be unhappy).
* It was missing dependencies on a couple of interface targets.

R=azani@chromium.org
BUG=fixes #792

Review URL: https://codereview.chromium.org/2049443002 .

[modify] https://crrev.com/5e6754ba911667ba425291992e162284f142726a/mojo/go/BUILD.gn

Project Member Comment 17 by bugdroid1@chromium.org, Jun 17 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/external/mojo.git/+/5e6754ba911667ba425291992e162284f142726a

commit 5e6754ba911667ba425291992e162284f142726a
Author: Viet-Trung Luu <viettrungluu@chromium.org>
Date: Tue Jun 07 20:13:47 2016

Fix the //mojo/go:application target.

* It was missing describer.go in its list of sources (so if you changed
  it, but nothing else caused the target to rebuild, you'd be unhappy).
* It was missing dependencies on a couple of interface targets.

R=azani@chromium.org
BUG=fixes #792

Review URL: https://codereview.chromium.org/2049443002 .

[modify] https://crrev.com/5e6754ba911667ba425291992e162284f142726a/mojo/go/BUILD.gn

Sign in to add a comment