Bug 6998

Summary: setTimeout(0) tight loop uses almost all CPU (need 10ms minimum for timeout?)
Product: WebKit Reporter: Sjoerd Mulder <sjoerdmulder>
Component: JavaScriptCoreAssignee: Darin Adler <darin>
Status: VERIFIED FIXED    
Severity: Major CC: ap, darin, ddkilzer, mjs
Priority: P2 Keywords: EasyFix, HasReduction
Version: 420+   
Hardware: Mac   
OS: Windows XP   
Bug Depends on:    
Bug Blocks: 6628    
Attachments:
Description Flags
Testcase
none
count the number of ticks in 1 second none

Sjoerd Mulder
Reported 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.
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
View All Add attachment proposed patch, testcase, etc.
Sjoerd Mulder
Comment 1 2006-02-01 01:52:18 PST
Created attachment 6177 [details] Testcase
David Kilzer (:ddkilzer)
Comment 2 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?
David Kilzer (:ddkilzer)
Comment 3 2006-02-01 04:37:21 PST
Blocker ("parent") is on HitList, so removing HitListCandidate keyword.
Alexey Proskuryakov
Comment 4 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?
Darin Adler
Comment 5 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?
Darin Adler
Comment 6 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.
Alexey Proskuryakov
Comment 7 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?
Darin Adler
Comment 8 2006-02-01 10:47:46 PST
It's trivial to put in a 10ms minimum -- I'll do that now.
Dave Hyatt
Comment 9 2006-02-01 13:37:54 PST
Yeah all the other browsers have a 10ms minimum. Guess we should too.
Darin Adler
Comment 10 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.
Sjoerd Mulder
Comment 11 2006-02-03 00:09:42 PST
Verified to be fixed on nightly build r12540
Geoffrey Garen
Comment 12 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.
Note You need to log in before you can comment on or make changes to this bug.