[pilif]

It's funny how everybody posts their theories of why the benchmark is wrong (or done by the wrong person) and nobody actually tries out the code they think is better. So instead of guessing, let's implement that corrected version of the node.js application and run the benchmark again.

In my case, I admit, I don't have Windows ready to reproduce the result, but then I'm also not complaining about how the test was done, nor do I care about this at the current point.

If I ever have issues with performance of an application, then I will be doing the profiling and evaluating other options. I certainly wouldn't use some benchmark I'm too lazy to reproduce as a basis for selecting the technology to use. Instead, I use the tool I'm most comfortable with, I see the most advantages from or I just like best.

While the OP's benchmark might have been (and IMHO probably was) flawed, at least they provided source code and documentation for us to improve and re-run it. That's way more important than to know who they are and what their motivations might be.

[ma2rten]

So instead of guessing, let's implement that corrected version of the node.js application and run the benchmark again.

As other comments pointed already out, the main flaw in this post is NOT that the node.js implementation is not as efficient as it could be. It is that the author choosed to benchmark a CPU intensive task, as opposed to an IO intensive one. This is not what node.js is good at nor what it is typically used for. That is something that can not be fixed without creating an entirely new benchmark.

I certainly wouldn't use some benchmark I'm too lazy to reproduce as a basis for selecting the technology to use.

However, it is good to have a general idea how different technologies compare. If for example you were to decide whether to learn node.js or C#, a benchmark like this might be one datapoint you could use.

One of the succesfactors of the Silicon Valley startup culture is open and honest feedback, even if it is sometimes not what you want to hear. There is not a culture of: "Do it better yourself, before you criticize others".

[rjzzleep]

imho, that's only half the problem. if you're bound to use .net for web stuff, chances are they will also force iis on you.

suddenly you can't use httplistener anymore and you have build an httpmodule for iis. so now you either build your own handler or use one of the existing ones.

i guess if you build your own isapi extension it's probably not very bad, but if you go through the asp.net "stack" it suddenly becomes a whole different story.

[JPKab]

This comment was made by a .NET lover on the article:

"Imagine that! An enterprise-class framework (.NET) is faster than Node.js (a boutique framework created just because someone could). Who woulda thunk it? Even if Node.js performed better, you couldn’t get me to switch. C# and .NET together are much, much too powerful a combination. With .NET I know that my application’s code will scale with my business."

sigh

This is why .NET can't have nice things. I have no issue with a lot of Microsoft's tools, but my God, the fanatical for no reason other than kool-aid training classes followers kill me.....

"scale with my business"??? Is he human, or is he a robot that randomly appends marketing slogans together into paragraphs?

[jzig]

He doesn't sound any different to me than most of the people here on HN that talk about scaling. SV has its own Kool-Aid ya know.

[JPKab]

Still, there is nothing that annoys me more than when someone who is well versed in one toolset, and new to another toolset has the audacity to conduct a comparison and pretend like they did it correctly.

I'm glad he provided source code, but he clearly doesn't know Node well enough to provide an Apples to Apples comparison. Maybe .NET will blow Node away? Fine, but make sure you know Node well before you do the test.

Still, it's a nice conversation to start. I don't care how much I hate the company that builds it: if a tool is best for a job I want to know about it.

But your complaint that nobody is doing the tests: C'mon, how many Node experts even have Windows laying around?

[angersock]

So, what's wrong with his Node code? What's the tell?

[thedufer]

He doesn't know that node is single-threaded. Take an embarrassingly-parallel task (serving multiple unrelated requests, for example) and pit a single thread against multiple threads. Guess who's going to win?

Depending on the size of the .NET's thread pool, this probably more than accounts for the difference. The drastic inefficencies from not knowing what the async library does are just icing.

[adandy]

Try it on mono?

[masklinn]

> It's funny how everybody posts their theories of why the benchmark is wrong (or done by the wrong person) and nobody actually tries out the code they think is better.

The problem here is that not only is the code essentially broken and doing an apple to barnacles comparison, the core idea of the benchmark pretty certainly plays against node's strength (IO, lots of connections) as most of the hard work is not IO.

[meryn]

"let's implement that corrected version of the node.js application and run the benchmark again." - Do it. I'm curious. :)

[adandy]

I'm not sure it would be worth it. While I think it is neat to finally see .NET popping up more I really don't see what this benchmark proves even if the C# and js both sorted the same type of data (string/floating point).