.NET and Node.JS – Performance Comparison

- Correct. I am saying that nodejs is slower in general. The reason you would use nodejs is to save development time, and not to extract the last drop of performance. It is for the same reason that people have written so many apps on Python and Ruby.

- I/O in nodejs is always asynchronous. I/O in typical .Net apps is almost always synchronous, due to programmer choice. This approach is followed in the vast majority of Asp.Net apps. So according to you, this would imply that most .Net programmers don't know how to program in .Net.

- I can't follow how "ORM magic" is related to I/O. The ORM magic I remember has been a terrible experience for me when I had to use .Net (3-4 years back). We have to write our own ORM to replace EF, since it was dog slow. Including the LINQ expression tree parser, design-time tools etc. You can find this result here: https://github.com/jeswin/AgileFx

I know that things finally got better after EF4. But I haven't worked much on .Net of late.

> Are you insinuating that there is deception being used here? or an inaccuracy?

I don't know what he's insinuating, but looking at the code and liking neither technology the bench does indeed look completely inaccurate (it's not even comparing apples and oranges, it's comparing bananas and clams) if not willingly deceptive: https://news.ycombinator.com/item?id=5460267

And PHP serves an empty page faster than Go splits strings. I declare PHP the winner by default.

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 Array.sort for the actual sorting. The only reason you'd want to use Async.sortBy is if the values that the array of "keys" is not known beforehand (and needed to be loaded through io - asynchronously). This is clearly exemplified in the documentation. https://github.com/caolan/async#sortBy

The implication of this that your call to async.sortby can be replaced by a call to array.sort. This will remove two unnecessary runs of async.map, inflicting a potentially huge performance penalty.

You do need to pass array.sort a comparator function, otherwise it will sort lexicographically (see https://developer.mozilla.org/en-US/docs/JavaScript/Referenc... ). That said, I'm not sure what the actual contents of your input file is. In your .Net example, you do not seem to bother to convert the array of strings to an array of ints (or floats). I think that .Net sort will sort an array of strings lexicographically as well. Furthermore, in the node.js example, you seem to be content with returning the resulting median as an int, not as float. Do the input "decimals" in the input file represent ints or floats? Do they all have exactly the same amount of decimals? Are both the Node.js and .Net algorithms doing the same thing? I think not.

Finally, we get to Array.sort. Array.sort blocks. Depending on the multi-threading efficiency of the underlying algorithm of Array.sort (which I don't have insight in), the code may not be able to use all available system resources. Keep in mind that Node.js is single-threaded. I practically don't know anything about .Net, but I assume it will magically start new processes and or threads if the runtime deems this beneficial. For Node.js, you may want to try the Cluster api, http://nodejs.org/api/cluster.html . You could try seeing if performance increases by adding one or more extra server processes.

I can't comment about the quality of the .net code since I don't have any experience with it.

I think it would be fair (and very educative to others) if you'd rerun the benchmarks with 1. Async.sortBy replaced with array.sort 2. with both .Net and Node.js algorithms fully doing the same thing (i.e. let them both sort either floats, ints, or strings), and 3. at least one extra server process for Node. I think most interesting would be if you'd made the changes step-by-step, and run the benchmarks at each step.

My guess is that step 1 would give the biggest difference. Depending on how you decide to resolve the differences in the two algorithms, performance of your .Net code may be slightly affected. It could potentially be speed up in fact, if somehow it's able to sort ints (or floats) faster than strings. The actual job of sorting probably overshadows it all though."

What do you guys think of this?