"Confirms it may not be ready"? Really?
I've just confirmed I may have solved cancer.
Node.js memory benchmark confirms V8's GC may not be ready for the server
31–40 of 43 posts
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#32Earlier quoted context omitted.
I think your conclusions in the article are fair. I think the title on HN is misleading because it's a quantitive issue. V8 GC is a well known concern in the Node community, but it's still performing well enough that Node is considerably faster than traditional servers (like Apache). The fact that Ringo is also faster doesn't make V8 "not ready" it just means it could be improved. If I wanted to be contentious I coul…
You are right about the title. That "not ready for the server" is a foolish phrase. I'd change it to "not tuned for the server" if I could, but it looks like it's impossible to change that now.
Maybe you could change it to "Not as optimized as Rhino to parse JSON under heavy load."
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#33Earlier quoted context omitted.
--trace-gc will show an endless sequence of mark-sweep/compacts. I explained why that happens in my comment to the original post.
Yes, --trace-gc shows about 10 Mark-sweeps per second, each taking around 13 ms (no compacts though as far as I could see). But are those ~15% spent in GC are enough to explain the performance?
You were saying that V8 GC is failing here so I just explained why JSON.parse is especially bad for V8 GC.
Strictly speaking I am not even convinced that GC is bottleneck here. Only profiling can reveal the real bottleneck.
[I tried small experiment: used thirdparty pure-JS JSON parser instead of V8 JSON.parse --- that changed GC profile, but did not affect response time.]
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#34I 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.
I think the main point of this post (and also the edited headline) is that this is not an issue of Node per se, but rather of V8.
Yeah, but if you mention Node.js in the title of a Hacker News post you're all but guaranteed to get on the front page.
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#35Earlier quoted context omitted.
Great comment! Anybody interested should check it out: http://hns.github.com/2010/09/29/benchmark2.html#comment-820...
It explains why JSON parsing doesn't perform well, but doesn't explain the original benchmark results. Would be great to get a comment from @mraleph or the other V8 guys on that.
Speaking about GC behavior of other benchmarks:
1) one with Buffers is also causing mark-sweep/compact pauses (7-15ms each) because Buffer constructor calls AdjustAmountOfExternalAllocatedMemory which triggers full gc cycle if it thinks that too much memory is held outside V8.
2) GCs in string based benchmark are mainly scavenges taking 0 ms plus That is all I can say. V8 GC is performing well here from my point of view.
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#36Earlier quoted context omitted.
It explains why JSON parsing doesn't perform well, but doesn't explain the original benchmark results. Would be great to get a comment from @mraleph or the other V8 guys on that.
Speaking about GC behavior of other benchmarks: 1) one with Buffers is also causing mark-sweep/compact pauses (7-15ms each) because Buffer constructor calls AdjustAmountOfExternalAllocatedMemory which triggers full gc cycle if it thinks that too much memory is held outside V8. 2) GCs in string based benchmark are mainly scavenges taking 0 ms plus That is all I can say. V8 GC is performing well here from my point of v…
I just found out the same. So I guess it must be some intra-VM data shifting? Anyway, I'll update my posting accordingly.
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#37I wonder what effect this will have in a memory constrained environment on say webOS.
The original Palm Pre only has 256MB of RAM and had plenty of "out of mem issues" prior to homebrew adding compcache
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#38I wonder what effect this will have in a memory constrained environment on say webOS.
The original Palm Pre only has 256MB of RAM and had plenty of "out of mem issues" prior to homebrew adding compcache
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#39I wonder what effect this will have in a memory constrained environment on say webOS.
The original Palm Pre only has 256MB of RAM and had plenty of "out of mem issues" prior to homebrew adding compcache
Re: Node.js memory benchmark confirms V8's GC may not be ready for the server
#40Earlier quoted context omitted.
Speaking about GC behavior of other benchmarks: 1) one with Buffers is also causing mark-sweep/compact pauses (7-15ms each) because Buffer constructor calls AdjustAmountOfExternalAllocatedMemory which triggers full gc cycle if it thinks that too much memory is held outside V8. 2) GCs in string based benchmark are mainly scavenges taking 0 ms plus That is all I can say. V8 GC is performing well here from my point of v…
I just found out the same. So I guess it must be some intra-VM data shifting? Anyway, I'll update my posting accordingly.
I don't know node.js well enough to even make a guess here. Somebody needs to profile it.
Updating your post sounds like a nice idea. It created a lot of confusion among developers.