Bug 6998 - setTimeout(0) tight loop uses almost all CPU (need 10ms minimum for timeout?)
: setTimeout(0) tight loop uses almost all CPU (need 10ms minimum for timeout?)
Status: VERIFIED FIXED
: WebKit
JavaScriptCore
: 420+
: Macintosh Windows XP
: P2 Major
Assigned To:
:
: EasyFix, HasReduction
:
: 6628
  Show dependency treegraph
 
Reported: 2006-02-01 01:51 PST by
Modified: 2008-09-29 15:24 PST (History)


Attachments
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 From 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() {
    setTimeout(testTimeout,0);
}

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 From 2006-02-01 01:52:18 PST -------
Created an attachment (id=6177) [details]
Testcase
------- Comment #2 From 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 From 2006-02-01 04:37:21 PST -------
Blocker ("parent") is on HitList, so removing HitListCandidate keyword.
------- Comment #4 From 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 From 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 From 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 From 2006-02-01 10:43:08 PST -------
Created an attachment (id=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 From 2006-02-01 10:47:46 PST -------
It's trivial to put in a 10ms minimum -- I'll do that now.
------- Comment #9 From 2006-02-01 13:37:54 PST -------
Yeah all the other browsers have a 10ms minimum.  Guess we should too.
------- Comment #10 From 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 From 2006-02-03 00:09:42 PST -------
Verified to be fixed on nightly build r12540
------- Comment #12 From 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.