hannesw

5 ms·

1.
by hannesw 15y ago
This is exactly where I want to go with RingoJS: Many threads with private mutable scope, global read-only scope, worker/actor based thread interop, one event loop per thread. Currently we still have shared mutable state that sometimes requ
2.
by hannesw 15y ago
I think the opinions expressed in this article are valid. However, I don't think the inability of current JavaScript to do async I/O without callbacks is Node's biggest problem. As others have said, it works for smaller projects (and even h
3.
by hannesw 15y ago
The only way to make it expand forever would be to support recursion. Would be interesting what texts you could come up with that. Kind of a textual Mandelbrot set.
4.
by hannesw 16y ago
Another important one is this: FOU: field-of-use restrictions (in the TCK license). http://skife.org/java/jcp/2010/12/07/the-tck-trap.html http://jcp.org/en/jsr/results?id=5111
5.
by hannesw 16y ago
Updated!
6.
by hannesw 16y ago
I just found out the same. So I guess it must be some intra-VM data shifting? Anyway, I'll update my posting accordingly.
7.
by hannesw 16y ago
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?
8.
by hannesw 16y ago
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.
9.
by hannesw 16y ago
Just an educated guess. If you're allocating tons of objects and strings and your app gets slow, it's very likely to be the GC. But I don't know V8 well enough to say for sure.
10.
by hannesw 16y ago
Most of these questions are answered in my original, longer post: http://hns.github.com/2010/09/21/benchmark.html . The JSON I'm parsing is just objects with short string properties (around 10 characters). There's just one longer 25kb JSON
11.
by hannesw 16y ago
I'm the author of both the original article and this HN posting - and yes, I am biased, since I'm the main developer of RingoJS (the other platform in that benchmark). I've made that quite clear and provided additional background in the ori
12.
Node.js memory benchmark confirms V8's GC may not be ready for the server(hns.github.com)
93 points by hannesw 16y ago|40 comments
13.
by hannesw 16y ago
I submitted a Ringo talk to JSConf.eu 2010, haven't heard anything back from these guys so far. If that fails, I may apply for next JSConf.us. We'll get the word out there eventually :)
14.
by hannesw 16y ago
We use Jetty's ability to do both sync and async HTTP in RingoJS. I've written about it here: http://hns.github.com/2010/07/02/versatility.html I think Netty is great if you want fine grained control over each aspect of your network stack
15.
Serving both sync and async/comet HTTP with RingoJS(hns.github.com)
13 points by hannesw 16y ago|2 comments
16.
by hannesw 16y ago
I know, i read that post. I'm planning to do a Node/Ringo comet comparison soon, and memory usage/max connections will be a part of that.
17.
by hannesw 16y ago
Comparing comet performance between node and ringo should be interesting. Ringo uses jetty/cometd, so it should scale pretty decently as well. My guess is that node will use less memory per connection (and thus allow more simultanous connec