I wrote this bench because I claimed yesterday that fibers can be 10 times
faster than callbacks on some code patterns and someone dismissed it with a
sarcasm. I was also getting really tired of all the FUD that people spread
around streamline and fibers.
This bench did not come from nowhere, it came from the experience of a real
development that I did with node last year. This dev consisted in porting a
complex component written in C to node. This code is doing I/O but it is
also executing complex logic with lots of loops, tests, exception handling,
etc. It is not "just another proxy".
As performance is a critical factor for this component I started to write
it with manual callbacks (yes, I can do this, and I can even enjoy it!). I
used nextTick to avoid stack overflow with loops but this was not fast
enough (half the speed of the original C component). So I replaced nextTick
by trampolines. This improved performance (component was only 20% slower
than the original C version) but the code became really hard to debug.
Around the same time Marcel Laverdet had written a fibers backend for
streamline. Fibers introduce overhead in I/O calls but they also make
everything else much leaner and thus faster: loops don't need to be
converted to recursive form any more, functions don't need to trampoline,
values are returned by a simple "return" statement, not by a callback, you
don't have to test for exceptions and propagate them with callbacks at
every level, you can just set up one try/catch at the high level, etc. I
did some small benchmarks which showed that fibers could be much faster on
some code patterns (10 times on caching patterns but a lot more on some
pathological recursive patterns).
I thought that, given the code patterns that I had in my component, fibers
might give faster code than callbacks overall. So I converted the code to
streamline and I executed it in fibers mode. The result is not 10 times
faster than the manually written version but it got a little closer to the
C version (almost on par). But the code was much simpler and debugging
became really pleasant (with meaningful stack traces). So I decided to
switch to streamline + fibers for this subproject.
Of course, the bench is not representative of what you will get on average
with fibers but it shows that fibers can speed up some patterns (caching in
this example). It also shows that manually written loops that use nextTick
to avoid stack overflow are slower than streamline generated loops that use
a trampoline variant instead.
I only have two comments for billywhyzz:
1) callback !== asynchronous: function(cb) { cb(); } is *not* an
asynchronous function. There is no reason to give it an _ parameter in
streamline and there is no need for an _ in the function that calls it
either. Your bench just shows that you don't understand streamline. Bench
with a real async call. With process.nextTick streamline (callback mode)
introduces a 50% overhead, with setTimeout(cb, 0), the overhead becomes
18%, if this can make you happy.
2) hacking the loop by going through nextTick once every 1000 iteration is
dangerous. Exit loop after 900 iterations => loop has eaten 1800 stack
frames. Do this a few times on different caches and you'll blow the stack.
The streamlined loop runs with a fixed stack depth.
On Wednesday, April 11, 2012 10:22:42 PM UTC+2, Bruno Jouhier wrote:
>
> https://gist.github.com/2362015
>
> fibers: 10 times faster!
> callbacks generated by streamline: almost 2 times faster!!! (find out why!)
>
> Bruno
>
On Wednesday, April 11, 2012 10:22:42 PM UTC+2, Bruno Jouhier wrote:
>
> https://gist.github.com/2362015
>
> fibers: 10 times faster!
> callbacks generated by streamline: almost 2 times faster!!! (find out why!)
>
> Bruno
>
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
