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 9 users

Issue metadata

Status: Duplicate
Owner: ----
Closed: Sep 2008
Cc:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.


Show other hotlists

Hotlists containing this issue:
test-group-edit-acl


Sign in to add a comment

setTimeout(..., 0) fires too quickly

Reported by jere...@gmail.com, Sep 3 2008

Issue description

Product Version      : 0.2.149.27 (1583)
URLs (if applicable) : http://ejohn.org/files/bugs/chrome/timer.html
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: OK
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. Open the above URL.
2. Wait a few seconds.

What is the expected result?
A number greater than 3000 should appear.

What happens instead?
A much smaller number appears - around 300-400.

Please provide any additional information below. Attach a screenshot if
possible.
Right now there is no delay inbetween setTimeout calls that have an
interval of 0ms. All other browsers provide a minimum delay of, at least
10ms. This rapid execution has the potential to create results which
execute too quickly (creating extraneous CPU overhead, as well). It should
probably be reduced to a consistent minimum, in line with other browsers.
 

Comment 1 by deanm@chromium.org, Sep 4 2008

If 0 is given shouldn't it execute immediately? If you want a delay of 10ms,
setTimeout(..., 10); it's not clear that this is an intentional feature rather than
poor performance on the other browsers
Status: Duplicate
I wrote up some of the justification for why we made this change in an external 
email.  Here are excerpts from that mail:

-------
First, the reason for this change is a fundamental belief that applications should be 
able to switch as quickly as possible between JS and the app.  An example would be a 
crypto function in JavaScript which took seconds to complete but which wanted to also 
update the UI.  Without this change, the CPU remains idle for far too long; 10ms is 
an eternity on modern processors. 

In considering this change, naturally we wondered if this would cause 
incompatibilities.   There were two cases we worried about.  First, sites which may 
cause your browser to tie up in knots if it went out of control too fast.  Second, 
sites which may depend on a particular interval.  The first case, turns out to be 
tricky for some browsers; the UI can lockup if the setTimeout pulses too quickly. 
Luckily, due to Chrome's multi-process model, UI responsiveness is not an issue for 
us.  The Chome UI can remain responsive even if a page is looping as fast as it can.  
To be conservative, we kept a clamp of 1ms in the code.  1ms on today's processors is 
still an eternity.  I look forward to removing this clamp someday :-)

The second case turns out to be a non issue. We observed that current browsers 
already do not have a stable and consistent clock.  As it turns out, even FF3 uses 
varying timer speeds of either 15.6ms or 10ms.  The reason for this variance is 
because FF3 uses the default windows timer mechanisms by default; which have a 15.6ms 
clock granularity.  However, these timers are influenced by the system-wide 
timeGetTime() API.  Flash, Quicktime, and Windows Media all set timeBeginPeriod(1), 
which changes the clock resolution to 1ms.  In this case, FF then applies a clamp to 
avoid sub-10ms timers.  This can be tested by starting with a blank system w/ only FF 
running, and using this tool: http://ejohn.org/apps/timers/  Then load youtube (flash 
causes the beginTimePeriod to be called) in a background tab and run your test again.  
You'll see the clock speed drop from 15ms to 10ms.  So, as you can see, a web 
developer today could be running IE w/ a 15ms minimum, FF, with a varying 10/15ms 
minimum, or another browser with who-knows-what for a minimum timeout.

My point is this - developers cannot count on any particular minimum value today.  
Another developer made a further excellent point.  Mobile devices may decide to opt 
for even slower clocks in order to trade-off between performance and battery life.  
Browsers must be free to change the minimal interval of setTimeout to optimize for 
that browser and platform, and in fact they already do this today.

As such, I believe the best analogy is the old "Turbo Button" which existed on early 
PCs.  As clock speeds sped from 33MHz to 66MHz, some poorly written applications 
which used the cycle counter as a clock broke.  Over time, these applications have 
been forced to rewrite.  Likewise, any applications dependent on a particular minimum 
setTimeout have the same problem.

After all that, I don't want you to think we wouldn't add a clamp under any 
circumstances.  We definitely would; especially in light of real world broken 
websites.  So far, we have not identified any.  I'm sure there are some.  We'd love 
to have examples.

The last thing to discuss are alternatives.  We could create a new API - 
"setTimeout2".  I don't have any other good ideas.
-------

The bug reporter says that he agrees with this approach.  We have a bug filed already 
for tracking any site incompatibilities which may arise because of this, so I'm 
dup'ing this out.  (see  bug 792 )

Comment 5 by omat...@gmail.com, Sep 4 2008

What are the issues if you really do execute the code immediately with 0 delay? (or 
rather add it to the event queue immediately, and execute it when the currently 
executing code and existing items in the queue are finished)

It would seem to me from the spec that SetTimeout(x,0) should mean "process all other 
pending events, and then process x".  By "all other events" I mean other on page 
events like bubbling through onclicks etc., but also in browser events like clicking 
the File menu.

Since all other events are processed first, it would be impossible to "lock up" a 
page by repeated calling of this even when the delay was 0.
There should not be issues; and if there are, there may be a bug.

The 1ms threshold was just to be conservative as we diverged from webkit.
Project Member

Comment 7 by bugdroid1@chromium.org, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit MuteOldIssue
Owner: ----
This issue has been in a closed state and not modified for over 3 years.  To ensure that discussions are happening in places where we are paying attention, we are closing comments and asking folks to please help us by filing "New Issue"s  for issues which have not been resolved.

Sign in to add a comment