To the author of this article: Could you run your node test with "node --trace-gc <script>" turned on? That will output when, and for how long, node's GC is doing it's thing.<p>Anyway, this could be a legit complaint at this point.
V8 has a very impressive garbage collector (stop-the-world, generational, accurate) and the GC is probably a part the Google team have spent a lot of time tuning and working on as it's one of the harder and most important parts of building a VM...<p>My guess is that node's GC configuration isn't finely tuned for 25KB structures or maybe the GC is called prematurely.<p>Some suggestions: try to turn off the GC and re-do the benchmark, try with smaller JSON datastructures, try with different versions of node. Each of these would give more evidence where the problem is.<p>Btw. in that benchmark: which versions of RingoJS and node.js are used? How much memory does each server use in the end?<p>Edit:
What type of garbage collector does RingoJS/Rhino use - how is the GC configured for RingoJS?
I think the editorializing of the headline is unnecessarily negative (read biased). There is obviously an issue Ryan is working on addressing but Node is clearly already providing performance which is suitable for many server workloads.
First, the response time variation is an important observation, thanks for that. To make sure, that it is caused by V8's CG, we need a GC log from the benchmark.<p>Second to make this a fair comparison, you need to use a similar sized heap. It could be, that the JVM heap was large enough to run the whole test without a major CG. We need a GC log also for this part of the test.<p>Sun was aware of the different CG strategies needed for server and client use and let us choose between them. V8 however seems the be optimized for the client side.
I'm not yet convinced this is due to GC. Sent a pull request[1] to Hannes to use the faster Buffer technique, to at least rule out the interference of v8's crazy slow string juggling under load.<p>1: <a href="http://github.com/hns/ringo-node-benchmark/pull/1" rel="nofollow">http://github.com/hns/ringo-node-benchmark/pull/1</a>
Has anyone done any experiements with node.js and Jägermonkey? They’re getting pretty close to V8 in speed ( <a href="http://arewefastyet.com/" rel="nofollow">http://arewefastyet.com/</a> ) and might prove better for server use (utter conjecture on my part).
I wonder what effect this will have in a memory constrained environment on say webOS.<p>The original Palm Pre only has 256MB of RAM and had plenty of "out of mem issues" prior to homebrew adding compcache
It seems like node performs better at the bottom of the curve where most of us are likely to be.<p>Can the performance issues be solved by adding hardware? (or spin up more node processes so that each one stays at the bottom of the curve?
python did not return any memory whatsoever to the operating system before 2.5.<p><a href="http://bugs.python.org/issue1123430" rel="nofollow">http://bugs.python.org/issue1123430</a>