6998 2006-02-01 01:51:30 -0800 setTimeout(0) tight loop uses almost all CPU (need 10ms minimum for timeout?) 2008-09-29 15:24:22 -0700 1 1 1 Unclassified WebKit JavaScriptCore 420+ Mac Windows XP VERIFIED FIXED EasyFix, HasReduction P2 Major --- 6628 1 sjoerdmulder darin ap darin ddkilzer mjs oldest_to_newest 30927 0 sjoerdmulder 2006-02-01 01:51:30 -0800 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. 30928 1 6177 sjoerdmulder 2006-02-01 01:52:18 -0800 Created attachment 6177 Testcase 30937 2 ddkilzer 2006-02-01 04:17:47 -0800 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? 30940 3 ddkilzer 2006-02-01 04:37:21 -0800 Blocker ("parent") is on HitList, so removing HitListCandidate keyword. 30954 4 ap 2006-02-01 05:58:02 -0800 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? 30975 5 darin 2006-02-01 09:20:35 -0800 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? 30976 6 darin 2006-02-01 09:21:31 -0800 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. 30984 7 6194 ap 2006-02-01 10:43:08 -0800 Created attachment 6194 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? 30985 8 darin 2006-02-01 10:47:46 -0800 It's trivial to put in a 10ms minimum -- I'll do that now. 30995 9 hyatt 2006-02-01 13:37:54 -0800 Yeah all the other browsers have a 10ms minimum. Guess we should too. 31090 10 darin 2006-02-02 09:32:16 -0800 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. 31123 11 sjoerdmulder 2006-02-03 00:09:42 -0800 Verified to be fixed on nightly build r12540 35546 12 ggaren 2006-03-08 10:35:27 -0800 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. 6177 2006-02-01 01:52:18 -0800 2006-02-01 01:52:18 -0800 Testcase timeout.html text/html 1098 sjoerdmulder PCEtLSAtLT4KPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgU3Ry aWN0Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXN0cmljdC5k dGQiPgo8aHRtbCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCIgeG1sbnM6Yj0i aHR0cDovL3d3dy5iYWNrYmFzZS5jb20vYiIgeG1sbnM6cz0iaHR0cDovL3d3dy5iYWNrYmFzZS5j b20vcyI+Cgk8aGVhZD4KCQk8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50LXR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiAvPgoJCTx0aXRsZT5QZXJmb3JtYW5jZSBw cm9ibGVtIFNhZmFyaSAvIFdlYmtpdDwvdGl0bGU+CgkJPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFz Y3JpcHQiPgoKCQkJZnVuY3Rpb24gdGVzdFRpbWVvdXQoKSB7CgkJCQlzZXRUaW1lb3V0KHRlc3RU aW1lb3V0LDApOwoJCQl9CgoJCTwvc2NyaXB0PgoJPC9oZWFkPgoJPGJvZHkgb25sb2FkPSJ0ZXN0 VGltZW91dCgpOyI+CgkJPGgyPlBlcmZvcm1hbmNlIG9mIDxjb2RlPnNldFRpbWVvdXQ8L2NvZGU+ IGZ1bmN0aW9uIGluIFNhZmFyaSAvIFdlYmtpdDwvaDI+CgkJPHA+VGhlIGZvbGxvd2luZyBjb2Rl IHNob3dzIGEgc2ltcGxlIGxvb3Agd2hpY2ggdXNlcyB0aGUgPGNvZGU+c2V0VGltZW91dDwvY29k ZT4gZnVuY3Rpb24gdG8gY2FsbCB0aGUgc2FtZSBmdW5jdGlvbiBhZ2FpbiwgYnV0IHdpdGhvdXQg dGhlIHBlcmZvcm1hbmNlIGRyYWluIG9mIGEgPGNvZGU+d2hpbGUodHJ1ZSk8L2NvZGU+IGxvb3Au PC9wPgoJCTxwPjxwcmU+ZnVuY3Rpb24gdGVzdFRpbWVvdXQoKSB7PGJyIC8+CglzZXRUaW1lb3V0 KHRlc3RUaW1lb3V0LDApOzxiciAvPgp9PC9wcmU+PC9wPgoJCTxwPlRoaXMgd29ya3MgcGVyZmVj dGx5IGluIEludGVybmV0IEV4cGxvcmVyLCBGaXJlZm94IGFuZCBPcGVyYS4gVGFraW5nIGFsbW9z dCAwJSBDUFUtdGltZS4gQnV0IFNhZmFyaSAvIFdlYmtpdCB0YWtlcyAxMDAlIG9mIENQVS10aW1l Li4uIFRoaXMgaXMgYSB2ZXJ5IHNlcmlvdXMgcGVyZm9ybWFuY2UgcHJvYmxlbS48L3A+Cgk8L2Jv ZHk+CjwvaHRtbD4KCgoK 6194 2006-02-01 10:43:08 -0800 2006-02-01 10:43:08 -0800 count the number of ticks in 1 second timeout.html text/html 1254 ap PCEtLSAtLT4KPCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgU3Ry aWN0Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXN0cmljdC5k dGQiPgo8aHRtbCB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCIgeG1sbnM6Yj0i aHR0cDovL3d3dy5iYWNrYmFzZS5jb20vYiIgeG1sbnM6cz0iaHR0cDovL3d3dy5iYWNrYmFzZS5j b20vcyI+Cgk8aGVhZD4KCQk8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50LXR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIiAvPgoJCTx0aXRsZT5QZXJmb3JtYW5jZSBw cm9ibGVtIFNhZmFyaSAvIFdlYmtpdDwvdGl0bGU+CgkJPHNjcmlwdCB0eXBlPSJ0ZXh0L2phdmFz Y3JpcHQiPgoJCQkKCQkJdmFyIGNvdW50OwoJCQkKCQkJZnVuY3Rpb24gdGVzdFRpbWVvdXQoKSB7 CgkJCQkrK2NvdW50OwoJCQkJc2V0VGltZW91dCh0ZXN0VGltZW91dCwwKTsKCQkJfQoJCQkKCQkJ ZnVuY3Rpb24gcmVwb3J0KCkgewoJCQkJYWxlcnQoIlRoZSB0aW1lciBoYXMgZmlyZWQgIiArIGNv dW50ICsgIiB0aW1lcy4iKTsKCQkJfQoKCQk8L3NjcmlwdD4KCTwvaGVhZD4KCTxib2R5IG9ubG9h ZD0iY291bnQ9MDsgdGVzdFRpbWVvdXQoKTsgc2V0VGltZW91dChyZXBvcnQsIDEwMDApOyI+CgkJ PGgyPlBlcmZvcm1hbmNlIG9mIDxjb2RlPnNldFRpbWVvdXQ8L2NvZGU+IGZ1bmN0aW9uIGluIFNh ZmFyaSAvIFdlYmtpdDwvaDI+CgkJPHA+VGhlIGZvbGxvd2luZyBjb2RlIHNob3dzIGEgc2ltcGxl IGxvb3Agd2hpY2ggdXNlcyB0aGUgPGNvZGU+c2V0VGltZW91dDwvY29kZT4gZnVuY3Rpb24gdG8g Y2FsbCB0aGUgc2FtZSBmdW5jdGlvbiBhZ2FpbiwgYnV0IHdpdGhvdXQgdGhlIHBlcmZvcm1hbmNl IGRyYWluIG9mIGEgPGNvZGU+d2hpbGUodHJ1ZSk8L2NvZGU+IGxvb3AuPC9wPgoJCTxwPjxwcmU+ ZnVuY3Rpb24gdGVzdFRpbWVvdXQoKSB7PGJyIC8+CglzZXRUaW1lb3V0KHRlc3RUaW1lb3V0LDAp OzxiciAvPgp9PC9wcmU+PC9wPgoJCTxwPlRoaXMgd29ya3MgcGVyZmVjdGx5IGluIEludGVybmV0 IEV4cGxvcmVyLCBGaXJlZm94IGFuZCBPcGVyYS4gVGFraW5nIGFsbW9zdCAwJSBDUFUtdGltZS4g QnV0IFNhZmFyaSAvIFdlYmtpdCB0YWtlcyAxMDAlIG9mIENQVS10aW1lLi4uIFRoaXMgaXMgYSB2 ZXJ5IHNlcmlvdXMgcGVyZm9ybWFuY2UgcHJvYmxlbS48L3A+Cgk8L2JvZHk+CjwvaHRtbD4KCgoK