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.<p>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.<p>If I ever have issues with performance of an application, <i>then</i> 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.<p>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.
Another "hey look, node.js isn't good at everything" post. I figured these would have stopped by now.<p>Why are you using an async sort function when you're not doing anything asynchronous in the sort callback? That's going to entail some overhead obviously, and it also can't take advantage of the sort optimizations v8 implements. Are you trying to show the overhead the asynchronous sort entails? Any overhead it causes would be easily outweighed by whatever asynchronous IO it's doing in that sort function anyway. It is negligible in comparison: not even worth pointing out.<p>> The key point I want to make is that I am using the async NPM instead of the default blocking Array.Sort.<p>I don't think you realize how this works. That async sort function is there to help deal with sort callbacks that already have to do something asynchronous. You're doing something synchronous and using that async sort function for no reason. If you're going to run these benchmarks, use the synchronous sort which can take advantage of certain optimizations. Or, you can also just do something actually asynchronous, which would justify using an async sort in the first place.
YAY! .Net sorts bytes faster than Async.js sorts floats. In similar news, Go seems to split strings faster than .Net sorts bytes on my laptop. Fascinating stuff.
The author notes about himself:<p><i>> I work for Microsoft as a software engineer for Bing in Silicon Valley. My group specializes in building platform and experiences for consumers.</i> ( <a href="http://www.salmanq.com/" rel="nofollow">http://www.salmanq.com/</a> )
A common cause of slowness in .net web app is multiple database round trips during a single request, all happening in sequence. You <i>can</i> write async database calls in .net but they're not the standard / path of least resistance, and by the time you app is hitting these issues, refactoring it all is a big undertaking.<p>The results do not surprise me, but what I find more interesting is how different ecosystems and frameworks can encourage your average developer to write scalable or non-scaleable apps. And I still think node's model has a lot going for in this regard.
This is terrible. You are benchmarking node.js on exactly the thing everyone knows it is terrible at. Besides that yiur scenario is completely unrealistic and your google efforts Should have tipped you off.
There are no results for sorting algorithms on node because nobody sorts on node.js. This is CS102.. Why would anyone ever sort more than 50 items on the server side of a web application.<p>.net is faster than node but you absolutely failed at showing it.
One main thing I found missing was the OS that the tests were run on. I am not even sure if Windows can be seen as intended OS for node.js. Was the comparison between .NET on Windows vs Node.js on Windows? That might not be fair on the node.js side.<p>PS: I am a .NET fan, so I want fair comparisons, if I were to use them :)
So .NET with its massive, stable, mature native sorting libs is faster at sorting than async.sortBy, which is about 25 lines of JS. Well, no surprises there.
async.sortBy is for sorting the results of an array of asynchronous functions. It is not an asynchronous sort. Let's see how it fares with process.nextTick(function(){array.sort()}) (or better still, threads-a-gogo).
I find all the framework comparisons or this technology vs. that technology somewhat interesting, but quite often useless in terms of decision making. Evaluating very specific routines and functionality of framework A vs. framework B is roughly equal to evaluating the performance of carburetors in two racecars. If the only thing I'm interested in is carburetor performance, then I doubt I'm going to win many races.<p>What comparison do I find useful? The one that incorporates everything my application must address -- db queries, page rendering, cpu activity, memory consumption, operations, maintenance, etc. Given that I need lots of things for my application, single-point comparisons just really don't provide me with much value.
Well, THIS is going to bring on the haters.<p>(keep in mind, microsoft haters, that microsoft is currently a HUGE proponent of node.js - a lot of the Azure Mobile Services and the like are built on node)
i might have missed something but it looks like the .NET version sorts by the string values and the nodejs one sorts by calling parseFloat on the string values first. presumably this is going to slow down the nodejs version.
In terms of VM performance, nobody would doubt that .Net (or the JVM) would outperform V8; especially in number crunching. If anything, the benchmarks are only proving that Node.js is fast enough.<p>However, I would guess that typical Node.js apps would be better at handling concurrent connections than typical Asp.Net apps; since Asp.Net apps are not usually written in non-blocking style.
I posted this comment:
"It's obvious that you're new to Node.js.<p>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).<p>As you can see in the source <a href="https://github.com/caolan/async/blob/master/lib/async.js#L359" rel="nofollow">https://github.com/caolan/async/blob/master/lib/async.js#L35...</a> 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. <a href="https://github.com/caolan/async#sortBy" rel="nofollow">https://github.com/caolan/async#sortBy</a><p>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.<p>You do need to pass array.sort a comparator function, otherwise it will sort lexicographically (see <a href="https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Array/sort" rel="nofollow">https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...</a> ). 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.<p>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, <a href="http://nodejs.org/api/cluster.html" rel="nofollow">http://nodejs.org/api/cluster.html</a> . You could try seeing if performance increases by adding one or more extra server processes.<p>I can't comment about the quality of the .net code since I don't have any experience with it.<p>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.<p>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."<p>What do you guys think of this?
Parsing floats rather than letting JS loose typing handle it for you kills your sort algorithm: <a href="http://jsperf.com/parse-or-no-parse-sort" rel="nofollow">http://jsperf.com/parse-or-no-parse-sort</a>
Technologies are tools in a toolbox. The bigger your toolbox is, the more complex and wonderful things can be built. For any given problem there are a number of parameters involved: available resources (skillsets, fun factor, hardware platform, OS, budget restrictions), time to market, expectations on scalability/security, functional requirements and so on. Thinking that one tool is inherently more suited to all tasks and problems is the equivalent of the old saying about the hammer.
I want to ask several question:<p>1. How many threads does the .Net Runtime use?<p>I know little about .Net, but I know C# is like Java. The Jvm with servlet will use many threads to serve, so that many cpu cores will be involved.<p>However, this is not the case for node. One node process will use just one thread(thought it is not the exact fact).<p>So it's unfair int programming model.<p>2. What's the hardware you use, how many cores is there?
It seems the blog had a kind of "invisible" filter on the comments, which made it appear there were zero comments, or one (your own) if you had posted one. Now a whole pile of comments have become visible (manually approved I think). Funny to see all the reactions. Most commenters were probably not aware of one another.
If you do research and analysis NOT to find out the answer to a question but rather to JUSTIFY the answer you have decided (without evidence) is correct then the value of the results is nil.
I'm sure someone can write an optimized algorithm for Node.JS that will be much faster than his (seemingly naive) implementation. Until then, I see a lot of bluster.