Live data from Hacker News

.NET and Node.JS – Performance Comparison

salmanq.com

91–100 of 119 posts

Re: .NET and Node.JS – Performance Comparison

#91
post #77

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…

> 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.

Re: .NET and Node.JS – Performance Comparison

#94
post #77

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…

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".

Re: .NET and Node.JS – Performance Comparison

#96

Earlier quoted context omitted.

What do you mean by supportable? I was happily using mono for a number of custom servers in a similar way a couple of years ago. You don't need any huge frameworks to make mono really useful.

What, you mean, unless you're doing something useful like trying to write a web app?

Writing web apps may seem like the only thing people do lately, but it's not. Given a choice of a number of languages and runtimes available 5 years ago for example, .net/mono was a perfect choice for a daemon dispatching jobs to a number of usb dongles where having a good ffi (p/invoke), nice io abstraction, async actions and database interface was important.

This is something you write from scratch. No big frameworks are involved. If I ever find I need MVC.net, I'll probably go with a completely different language.

Re: .NET and Node.JS – Performance Comparison

#97
post #94
post #77

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…

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…

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.

Re: .NET and Node.JS – Performance Comparison

#98
post #82
post #77

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…

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…

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

Re: .NET and Node.JS – Performance Comparison

#99
post #88
post #67

Earlier quoted context omitted.

Its not only that. For me, Visual Studio, the best single piece of software ever made, should be made available too - which unfortunately probably ain't gonna happen. It just saves so much time and makes the process such a breeze, that it was what converted me to windows to begin with...

Visual Studio is the greatest set of training wheels ever made. Beautiful, shiny training wheels that let you coast along and drink and eat without worrying about falling over. The people using the training wheels just don't understand why the big kids flying by on only two wheels would ever do such a thing. It's so much harder! I don't want to make my life harder. I have code completion and fantastic syntax, error d…

Why did you go to all that trouble to make an analogy when you have no evidence to back it up?

Re: .NET and Node.JS – Performance Comparison

#100
post #69
post #48

I posted this comment: "It's obvious that you're new to Node.js. First of all, you should be aware that Async.js is a mere flow-control library. It does not offload work to separate threads, and neither is it able to parallelize work. Internally, it mostly does bean-counting (but very helpfully so). As you can see in the source https://github.com/caolan/async/blob/master/lib/async.js#L35... async.sortBy simply uses A…

Thinking this through some more, using sort with a comparator function would be unnecessary slow. Given the objective of the algoritm (return a median), it's much better to convert the array of strings to an array of floats (or ints, whatever he wants) first.

Or to simply use a selection algorithm instead of a sort, since they are asymptotically faster.
Post reply on HN