Bug 6998 - setTimeout(0) tight loop uses almost all CPU (need 10ms minimum for timeout?)
Summary: setTimeout(0) tight loop uses almost all CPU (need 10ms minimum for timeout?)
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 420+
Hardware: Macintosh Windows XP
: P2 Major
Assignee: Darin Adler
Keywords: EasyFix, HasReduction
Depends on:
Blocks: 6628
  Show dependency treegraph
Reported: 2006-02-01 01:51 PST by Sjoerd Mulder
Modified: 2008-09-29 15:24 PDT (History)
4 users (show)

See Also:

Testcase (1.07 KB, text/html)
2006-02-01 01:52 PST, Sjoerd Mulder
no flags Details
count the number of ticks in 1 second (1.22 KB, text/html)
2006-02-01 10:43 PST, Alexey Proskuryakov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sjoerd Mulder 2006-02-01 01:51:30 PST
The following code shows a simple loop which uses the setTimeout function to call the same function again, but without the performance drain of a while(true) loop.

function testTimeout() {

This works perfectly in Internet Explorer, Firefox and Opera. Taking almost 0% CPU-time. But Safari / Webkit takes 100% of CPU-time... This is a very serious performance problem. With setTimeout on 1 ms, it takes 25% which is still unacceptable.
Comment 1 Sjoerd Mulder 2006-02-01 01:52:18 PST
Created attachment 6177 [details]
Comment 2 David Kilzer (:ddkilzer) 2006-02-01 04:17:47 PST
Confirmed bug on Safari 2.0.3 (417.8) and nightly r12504 on Mac OS X 10.4.4.

Test case consumes close to 100% CPU while the test is running.  Changing to P1 due to poor performance.

Adding HasReduction and HitListCandidate keywords.  Do we need a "Performance" keyword, too?
Comment 3 David Kilzer (:ddkilzer) 2006-02-01 04:37:21 PST
Blocker ("parent") is on HitList, so removing HitListCandidate keyword.
Comment 4 Alexey Proskuryakov 2006-02-01 05:58:02 PST
I'm wondering what the explanation of low processor usage in other browsers is - actually, 100% processor usage looks like what is explicitly requested here (similar to a while(true) loop). Probably I'm missing something.

BTW, Win32 timers wouldn't honor a timeout lower than a certain threshold (normally, 10 ms). Maybe Firefox emulates this behavior?
Comment 5 Darin Adler 2006-02-01 09:20:35 PST
I'm not sure why this is a bug. Are we supposed to run JavaScript programs more slowly so they don't take so much CPU time? The program asks to run as fast as possible.

Maybe we need a version that counts how many times it runs, then we can write a bug for those other browsers about the fact that they run setTimeout too slowly?
Comment 6 Darin Adler 2006-02-01 09:21:31 PST
The 10ms minimum of Windows is probably the issue here.

We can easily hobble our timers so they can't fire in less than 10ms -- presumably that will fix this.

This is not a P1 bug.
Comment 7 Alexey Proskuryakov 2006-02-01 10:43:08 PST
Created attachment 6194 [details]
count the number of ticks in 1 second

Indeed, Firefox and Opera both limit their timers to 10ms, even on the Mac.

For 10ms timers, Safari seems to take slightly more CPU time than Firefox, but less than Opera (respectively 3.7%, 3.1%, 6.5% on my dual G4, as observed with top).

Given the workaround of explicitly using a 10ms timeout, should this issue be removed from the list of Backbase blockers?
Comment 8 Darin Adler 2006-02-01 10:47:46 PST
It's trivial to put in a 10ms minimum -- I'll do that now.
Comment 9 Dave Hyatt 2006-02-01 13:37:54 PST
Yeah all the other browsers have a 10ms minimum.  Guess we should too.
Comment 10 Darin Adler 2006-02-02 09:32:16 PST
I recommend that the application in question be changed to only request 10 ms if it doesn't really want to be called as often as possible.

I've now made WebKit standard and unwilling to fire timers faster than that, but it's really a mistake to ask for timeout 0 if you don't want to be called as fast as you can.
Comment 11 Sjoerd Mulder 2006-02-03 00:09:42 PST
Verified to be fixed on nightly build r12540
Comment 12 Geoffrey Garen 2006-03-08 10:35:27 PST
FYI, it seems that MapQuest uses the same technique, which was the cause of <rdar://problem/4289661> MapQuest.com map in Safari uses all CPU, but not on Internet Explorer.