Callbacks vs Fibers Memory Consumption Benchmark

91 views
Skip to first unread message

Alexey Petrushin

unread,
Aug 1, 2014, 5:07:24 PM8/1/14
to nod...@googlegroups.com
There where talk about disadvantage of using Fibers because it has huge stack and consumes more memory.

I wanted to know exactly how much more memory it consumes and created simple test - it creates 8000 callbacks & 8000 fibers and you can measure how much memory each version consumes.

8000 Callbacks - 13 MB
8000 Fibers - 90 MB

1. Seems like huge difference? I don't think so. In most web projects (practically all classical web apps, like express.js etc.) you don't deal with huge amount of requests, maybe couple tens or hundreds per second. 

3. Even in 10k apps - node can serve maybe 1-4000 on one machine, so, the difference would be much less, something around 12Mb vs. 40Mb.

3. It's an empty sample, in most cases you use some data inside it - it takes memory - and the results would be more even.


Would be interesting to know what do you think about it? Maybe there are points I missed?

Ben Noordhuis

unread,
Aug 2, 2014, 2:32:59 PM8/2/14
to nod...@googlegroups.com
A fiber's stack is allocated on demand. The fibers aren't doing much
in your test so their stacks stay small but in a real application,
each fiber's stack size will be anywhere from a few 10 kBs to up to 1
MB (the limit on x64).

That means those 8,000 fibers can use up to 8 GB of memory. That's
not a strictly theoretical upper bound either; many operations in V8
use liberal amounts of stack space, like parsing JSON, string
manipulation, regular expressions, etc.

A second gotcha is that fibers are implemented as mostly weak
persistent objects that require a special post-processing step in V8's
garbage collector. You probably won't notice it in short-running
tests but in long-running applications, you may see a significant
uptick in time spent inside the collector.

If you're targeting v0.11, generator functions let you do most of what
node-fibers can do at a lower overhead per coroutine. That's not to
disparage node-fibers, by the way. I quite like its simple
concurrency model and its rather ingenious implementation.
Reply all
Reply to author
Forward
0 new messages