
How to setTimeout with a delay less than 10ms - bluesmoon
http://dbaron.org/log/20100309-faster-timeouts
======
yason
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.

~~~
silvestrov
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.

~~~
geocar
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.

------
jasonkester
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.

------
geocar
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.

~~~
TrevorBurnham
Interesting. Is this in production use anywhere?

~~~
geocar
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>

------
Torn
Opera 10.5 the code is significantly faster:

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

------
invisible
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()();

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

~~~
invisible
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.

