Hacker News new | past | comments | ask | show | jobs | submit login
How to setTimeout with a delay less than 10ms (dbaron.org)
21 points by bluesmoon on March 20, 2010 | hide | past | favorite | 11 comments



And this would be completely unnecessary if the JS code didn't run in the UI thread or in connection with the page (via user events). The reason to split up work and play with setTimeout() and friends is to avoid UI/page lock-ups or triggering the script max run timeout.

It's effectively co-operative multitasking where I trust the responsiveness of my browser to some random web coder.


The html5 web workers is the proposed long term solution: http://ejohn.org/blog/web-workers/

Writing GUI libraries (as the DOM is) which works with multithreaded code is hard, very hard, and often have awful performance.

So realistic solutions need to trade something: use co-operative multitasking or loose access to the DOM.


Well actually, there may be other ways, for example it may be possible to detect conflicts!

Run the code in separate threads, and then at the end of the routine (or at synchronization points) check for a conflict. If there was a conflict, re-run the code in-order.


From the Mozilla site on window.postMessage:

  Introduced in Gecko 1.9
  (Firefox 3)
In other words, "Available 5 years from now."

If you want to use this today, you'll still need to sniff for it and call setTimeout if it's not available. So unless those 10ms are really important to what you're doing, this will just cost you more work.

That's the problem with cool new browser features. It just takes forever before they trickle down to enough of your users that it makes sense to use them.

Sometimes it's worth the wait. I can remember thinking all of the above about xmlHttpRequest and how lame it was that I'd still need to switch on it and have Netscape continue to use IFrames to do asynch communication back when IE5 came out.


I'm aware of another, similar trick:

    var i=new Image();
    i.onload=i.onerror=fn;
    i.src='about:blank';
It's faster than setTimeout, and it's more compatible than postMessage.


Interesting. Is this in production use anywhere?


The biggest impetus is MSIE's early onload bug, so while this trick supports more browsers, it still doesn't support the one you want it to.

I hacked up David Baron's demonstration so you can see it for yourself:

http://geocar.sdf1.org/zero-timeout.html


Opera 10.5 the code is significantly faster:

  100 iterations of setZeroTimeout took 3 milliseconds.
  100 iterations of setTimeout(0) took 609 milliseconds.


Neat concept - and it looks like it could work in IE8+ (with some code changes) and everything else.

One thing which may speed it up over many iterations is not setting the var fn and instead doing:

                    timeouts.shift()();


The overhead of setting the var is negligible compared with the other things happening in the event loop.


I suspected so, but I thought I'd throw that in anyway (who knows - maybe it would matter on IE). I prefer not setting variables if they're unneeded regardless.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: