undefined | Better HN

0 pointsexabrial12y ago0 comments

Well no matter what you use, you should always benchmark for that exact reason. Making things go fast takes a lot of performance engineering, and the JVM has millions of dollars worth of tuning put into it.

BTW, if you like Node.js, you should probably look at Vert.x. I haven't used it, but it's a similar concept, it runs on the JVM, and it seems to spank Node.js.

0 comments

tlear12y ago

When you benchmark Vert.x on a multicore system vs 1 node process. Now add multiple node processes to occupy the cores and store changes completely

aphyr12y ago

Indeed. Node's IPC costs are orders of magnitude slower than Java's volatile or atomic datatypes. I would only choose Node for stateless or trivially parallelizable problems--e.g., those where I could push the state problem into a runtime with real threads.

http://aphyr.com/posts/244-context-switches-and-serializatio...

qw12y ago

The benchmark is using multiple Node processes.

j / k navigate · click thread line to collapse