Bug 6998 – setTimeout(0) tight loop uses almost all CPU (need 10ms minimum for timeout?)

• Component: JavaScriptCore
• Status: VERIFIED FIXED

[Sjoerd Mulder]

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.

[Sjoerd Mulder]

Created attachment 6177 [details]
Testcase

[David Kilzer (:ddkilzer)]

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?

[David Kilzer (:ddkilzer)]

Blocker ("parent") is on HitList, so removing HitListCandidate keyword.

[Alexey Proskuryakov]

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?

[Darin Adler]

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?

[Darin Adler]

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.

[Alexey Proskuryakov]

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?

[Darin Adler]

It's trivial to put in a 10ms minimum -- I'll do that now.

[Dave Hyatt]

Yeah all the other browsers have a 10ms minimum.  Guess we should too.

[Darin Adler]

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.

[Sjoerd Mulder]

Verified to be fixed on nightly build r12540

[Geoffrey Garen]

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.