.NET and Node.JS – Performance Comparison
salmanq.comIt'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.
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".
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.
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?
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.
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?
So, what's wrong with his Node code? What's the tell?
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.
Try it on mono?
> 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.
"let's implement that corrected version of the node.js application and run the benchmark again." - Do it. I'm curious. :)
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).
Another "hey look, node.js isn't good at everything" post. I figured these would have stopped by now.
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.
> The key point I want to make is that I am using the async NPM instead of the default blocking Array.Sort.
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.
And PHP serves an empty page faster than Go splits strings. I declare PHP the winner by default.
I have bad news:
------------------
% time ./test.go "test1,test2,test3"
["test1" "test2" "test3"]
0.00s user 0.00s system 79% cpu 0.005 total
------------------
% time php -r ''
0.03s user 0.01s system 93% cpu 0.044 total
...and I have good news :-)
cd ~ > empty php -S localhost:8080 ## on the other console time { echo -e 'GET /empty HTTP/1.1\n\n' | nc localhost 8080 >/dev/null; } real 0m0.003s user 0m0.001s sys 0m0.000s
.NET native list sorting and Node.JS async.sortBy - Performance Comparison
Fixed that for ya.
And it's important to note that the comparison does not make sense: TFAA seems to believe "async.sortBy" performs an asynchronous sort (e.g. delegates the sorting to a threadpool) and that's how he implemented his own "SortAsync": to perform a regular Array.Sort in its own task.
But that's not what async.sortBy does according to its documentation, async.sortBy is used to sort using an async comparator/key function e.g. to sort file names using a stat(2) call, the .Net version would have to sort using an asynchronous IComparator of some sort.
edit: plus, for some reason the benchmark explicitly parses the input strings to floats in javascript (and sorts using that), but seems to sort the raw bytes in the .net version. The C# version further performs the string split in the sparked task, where it's performed in request in JS (not that it'd help since — as I mentioned — the sort itself is incorrect)
second edit: to be fair, I like neither technology and am not a specialist in either, I have a pretty basic basic grasp of both and thus may have made mistakes in my cursory reading, if I have and somebody knows better don't hesitate correcting me.
But as you may see from the paragraphs above, as far as I understand the code this comparison is complete nonsense (even ignoring the rather dubious higher level case of reading a single big file in memory at once, sorting it and extracting a bit of stat, which is unlikely to be IO-bound)
Exactly my thought. Was going to write a lengthy comment but yours has my main idea summarised perfectly.
The author notes about himself:
> I work for Microsoft as a software engineer for Bing in Silicon Valley. My group specializes in building platform and experiences for consumers. ( http://www.salmanq.com/ )
I just want to point out (as a Microsoft employee) that Microsoft is very actively using node.js internally. Many services are already using it and many more are starting projects with it.
I suspect the author did this as an evaluation to see which would work best for a future project, not a teardown piece on the platform. We really love node.js - seriously!
My friend works now for Skype/rosoft and they hired him particularly because of his knowledge of Node.js and JavaScript.
Unless you can point to something incorrect or unfairly biased in that article - why does this matter?
It's a benchmark of .Net's Array.Sort to NPM's third-party async.sortBy, not a benchmark of .Net to Node, and the test does not make sense: async.sortBy is used to sort an array on an asynchronous function, it does not perform an asynchronous sort (which is what the asynchronized Array.Sort does)
I agree with that and it's a fair comment. I'm just opposed to bias just because someone works for X.
And I agree, character assassination is no good.
On the other hand, when the author has a hand in one of the pots it very commonly results in a biased or incorrect comparison if only due to incorrect interpretation of the other tech, so defaulting to dismissal is not a bad heuristic either as first-order filtering to know whether there's a point in spending time in evaluating the post.
Especially when there's no clear up-front disclaimer of the conflict of interest, and here there is not (I went back to check, the post does not specify he works at Microsoft, you have to go and check his about page and/or blog history to realize that he's posting about MS tech all the time)
Because .NET is Microsoft's baby? How is this not a huge conflict of interest? At the very least, he should put a disclaimer of that conflict somewhere in the article.
Are you insinuating that there is deception being used here? or an inaccuracy? If the blog post was by a node contribute, would you cry foul for that as well? how about giving some counter points against the substance of the blog instead of just attacking the author's credibility based on where he is employed. I am guessing that since you cannot disagree with what was actually said and done by the author, you are grasping at the default fallacy of attacking his character and honesty.
>Are you insinuating that there is deception being used here? or an inaccuracy?
It could be both, and we should investigate both cases. Why should he get a clear pass?
>If the blog post was by a node contribute, would you cry foul for that as well?
If it was skewed towards node and/or he didn't mention it, then sure.
>how about giving some counter points against the substance of the blog instead of just attacking the author's credibility based on where he is employed.
The blog post has no substance to begin with. The comparison is bogus and the assumptions he makes do not stand. There are already about 20 comments in this thread as to why this is.
> 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
Yes when the author writes in the closing paragraph like this:
And that is when you realize that you have such a powerful, flexible framework like .NET under you fingertips with amazing performance like we’ve shown today.
At minimum you should use or have an expert in Node.JS (etc) to make sure things are done efficiently or used in the manner that makes sense for the use case.
While others have pointed out the issues, it is a critical observation to make because it often goes with a very strong selection bias. When someone wants to write that A is better than B -- which would be the obvious motivation of a Microsoft employee -- they will iterate through the cases until they can find evidence that they think supports that conclusion, then publishing that alone. In this case a rather terrible benchmark that, as so many others have mentioned, is really a sort comparison (against an incorrectly done node js sort, making it even worse).
I love .NET. I also love nodejs. The truth is that node is best as a glue system between technologies, and it works perfectly there.
I know nothing about node but the last paragraph of the article reads like it came directly from Microsoft's marketing material. Shame, because it makes me doubt the rest of what was a very interesting comparison.
A common cause of slowness in .net web app is multiple database round trips during a single request, all happening in sequence. You can 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.
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.
With C# 5's async features ... a lot of code can now easily be non-blocking by default. Even making asynchronous actions in asp.net mvc can have an enormously positive impact on server scalability. Just because you can write synchronous/blocking code doesn't limit the power of the platform when it's written using the latest features.
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.
.net is faster than node but you absolutely failed at showing it.
I don't program in nodejs but this is wrong on so many levels. First an honest question: what exactly is it that nodejs is terrible at? Please define it.
Now granted every tool has its strengths and weaknesses this benchmark shows a very large difference in operations that aren't uncommon in web servers.
Sorting in memory should concern you, since caching happens in the memory. Again, I don't know the state of ORM technology in nodejs but any NHibernate user will be able to tell you that level 2 caches are a common thing and they will boost the benchmarks even further if you were to compare it to a nodejs stack.
The only scenario where I see nodejs faster and better than .NET are the very smallish script scenarios like a log receiver etc, where no state is needed and minimal memory footprint is required
It wasn't wrong on many levels.
- For very obvious reasons, JS (or Python or Ruby) would be slower than Java, C# at number crunching.
- Node.js would handle concurrent connections better than most Asp.Net apps since the framework is non-blocking. Now you could write non-blocking code with .Net, but that isn't how most people write Asp.Net code. OTOH, with Node.js that's the only way you could write an app.
- I am impressed that Node.js actually performed this well in that benchmark. For a dynamic, hard-to-optimize language, being 2.5x slower than .Net (or Java) code is a fairly good result.
So you are saying that nodejs is slower in general, and .NET is slower when people don't know how to program in .NET.
To add on top of that, mvc 4 has extremely easy ways to set up async controllers/tasks. However, these are not needed or even WANTED most of the times. They are only really needed in I/O operations, a sector in which .NET excels anyway since you can get ORM magic happening easily.
Also, don't think non-blocking is really non-blocking. What can nodejs when it's waiting for the SQL lock to be lifted? (If there is any)
> Also, don't think non-blocking is really non-blocking. What can nodejs when it's waiting for the SQL lock to be lifted? (If there is any)
Node has a queue of stuff in the form of an event/message loop. It simply takes the next thing in the queue or it goes idle. That's why in Node you generally try not to do computational intensive tasks, because they hold the queue and it can't take any new requests.
- 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.
> 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
Nitpick: actually Node lets you do synchronous IO (http://nodejs.org/api/fs.html#fs_fs_readfilesync_filename_op...). Sometimes you can chose to use synchronous IO, for instance to do something in the initialization phase of your server.
Yeah I like the flexibility of nodejs and thats the reason I want to try it. It seems too cumbersome to setup an IIS website etc just to try some simple stuff.
As far as ORM go EF is kind of OK but its not really mature even at its current release. IMO NHibernate is the way to go, and boy its a good way... There are also others that are even faster than NHibernate but its the most fully featured and easily extensible so I just love it
Node has threads behind the scenes. The average developer can touch them. As a result, you can make 3 async calls with node and you end up only waiting on the slowest. As a result when the slowest returns you've got all the data needed by the controllers/views. Thus your overall system improves.
You could do this with ASP.NET MVC if you're not using the databindings on the front end and your willing to make your service layer a bit more complex. The code behind could call the service layer, which in turn calls three async methods (futures) that would return your data set. Then the service happily chugs along once it's got its data. This just isn't normaly in .NET world.
Buddy, get a clue pls. What databindings in MVC?? C# 5 support for async is excellent (almost as good as F#), recently Python's Guido said he's gone copy that syntax to Python. I don't know what you mean by normaly, I use it everyday.
I know that you could some async stuff all the way back with 2.0, but I have never been fortunate enough to be on an enterprise project that uses it. As a result of that and watching questions on StackOverflow I didn't think that such development behavior was common.
There was async stuff in 1.0, but the really good stuff came with version 4.0 and 4.5. The Task Parallel Library is a very nice implementation of the Promise/Future pattern, that came from the functional programming world.
Until Mono becomes 100% supportable, none of the advantages of .NET outweigh the misery of having to use Windows for development and serving.
I've put my foot down as long as I could about the joys of developing on Windows. But, since I've moved onto doing PHP and Python (with sprinkles of Ruby) full-time, I can't any longer.
Windows has come a long way in terms of development of non-.NET languages. But, there are still too many idiosyncrasies to function as a full-time platform for many languages.
Seems like my base need for Photoshop will push me to Mac sooner than I'd like.
care to name examples ? from my experience, especially when doing web development, the OS your tools run on does not really matter anymore.
A number of Python and PHP extensions either aren't up to date or don't work at all. Memcached comes to mind.
i run my dev enviroment in the cloud on ubuntu vms, just my editor and terminal client are on windows or osx if i happen to work on my laptop. So the OS doesnt really matter. If you run everything on the local machine, sure windows might not be ideal, but i dont consider that good practice anyway.
Mono is as "100% supportable" as any other open source stack, including Node.
Um. Mono supports just about everything these days: http://www.mono-project.com/Compatibility
There is a reason why people are using it to simultaneously develop for Win, OSX, Linux, Android, iOS, XBOX, Wii, etc....
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 detection etc. Why would I give that up and make my life harder? But when you give it up, you soon start to learn to find the errors yourself.... your memory picks up again. Think about how many phone numbers you knew before you stored them all in a cell phone. Think about how many you know now....
Every tool user will think tools more complicated than there's are ridiculous. Visual Studio users will think Sublime Text users are morons who are making their lives harder for no reason. Sublime Text users will think this about Vim users...... but my analogy:
Visual Studio: training wheels Sublime Text: fat tire 5 speed bike Vim/Emacs: 21 speed skinny tire Tour de France bike
I'm not sure many people would use Vim/Emacs in real life. I don't know... maybe some people... certainly not pros.
so what you are saying is that the many brilliant game programmers, including the likes of John Carmack or Tim Sweeny, dont know what they are doing ? Not everyone in IT is writing dead simple CRUD web apps using scripting languages, but those guys seem to have the biggest egos...
Honestly, what percentage of Visual Studio users are building game engines, vs. using it for building ridiculously overwrought MS apps that achieve the same functionality as a dead simple CRUD app (I'm looking at you Sharepoint)
Why did you go to all that trouble to make an analogy when you have no evidence to back it up?
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.
What if you already have code written in MVC.NET?
I couldn't get an ASP.NET 3.5 app running a while back.
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.
PS: I am a .NET fan, so I want fair comparisons, if I were to use them :)
I've run a few small test to see how Windows and Linux implementations of Node compare and Windows came on top every time. I think Microsoft put a lot of effort into a proper port, using Windows excellent I/O Completion Ports. Plus I don't think Google could ignore Windows performance when developing V8.
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.
Worse, it's a complete misuse and misunderstanding of async.sortBy: TFA implements a "SortAsync" by performing a Sort call in its own task, byt async.sortBy uses a task (an async callback) as its key function, so it calls and waits on a callback for each item in the original array where SortAsync TFA's SortAsync just blasts a single native Sort when the task runs.
Except, .NET sorting is implemenented in C# itself, not with native code.
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.
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.
Javascript is slower at sorting numbers then .Net!
mind blown
Well, THIS is going to bring on the haters.
(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.
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.
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?
Good break down of .NET Array.sort
It's kind of funny he talks about it being fast for due to non-blocking IO:
One of the key reasons most argue is that node.js is fast, scalable because of forced non-blocking IO, and it’s efficient use of a single threaded model.
...then goes on and sets up a benchmark which is more dependent on CPU than IO. Not to mention as mentioned here that benchmark itself is flawed.
In my experience Node is faster in the case of most web apps that select a row from the db, read network requests to do aggregation, or update a column in a db. Anything that does do CPU computation generally uses a native hook or a different tech altogether.
"...then goes on and sets up a benchmark which is more dependent on CPU than IO. Not to mention as mentioned here that benchmark itself is flawed."
Thank you. It amazes me how some people can write code in a framework like Node without even understanding the event-driven paradigm's strength and weaknesses. I was sitting there reading it, and then he states he is using a file sort??? WTF? As if anyone would use Node for that purpose.
I wrote a blog post with the correct node.js version: http://guillaume86.calepin.co/dotnet-vs-nodejs-performance.h...
The big performance hit for the node version is the float conversion.
Multithreaded .NET version is a bit harder to write because usually this work is delagated to ASP.NET/IIS.
UPDATE: the .NET version is actually already multithreaded because of the Task system, so Node.JS seems to be actually faster in this scenario...
I ran it too and came to the same conclusion: problem in the original comparison is that CPU usage of the node version never gets over 40% on my laptop, while the .NET version uses 100%. Using Array.sort() makes little difference. Adding threads to the node version does. I think also adding threads to the .net version wont help it much; it already uses 100% CPU.
Good idea to look at the CPU usage. To be complete I should show CPU/Memory usage under load but I've already spent enough time on this ;).
See my own notes on the issues I see in the code: https://news.ycombinator.com/item?id=5460267
> I can't comment about the quality of the .net code since I don't have any experience with it.
I'm by no means a .NET guru, but reading his code a couple non-optimal points jumped out at me:
- after parsing the file into an Array, he needlessly converts it into a List (while calling his variable 'array'). How bad this is is hard to say -- if the .NET compiler is sufficiently smart enough, it could optimize this to just a wrap operation, since the default List implementation uses an Array internally. That seems unlikely to me though. You'd have to check the generated code and benchmark.
- by sorting with the default string comparator, he's doing a culturally-aware unicode sort. I.e., the values are being sorted to "alphabetical" order, for however Unicode defines "alphabetical" for his current culture setting. A lot of people seem to feel it's obviously faster to compare the strings than the parsed floats. I don't think that's at all obvious.
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.
meryn this is an opportunity for you to properly design a benchmark and write your own blog post.
EDIT: I meant to imply that most people who write benchmarks usually aren't experts in every language/framework in the comparison, so it would be nice to see someone who is competent in both .NET and in nodejs put together a benchmark.
I'll take that as a compliment. ;)
If I ever would be doing such a thing, it would be more of a lesson in how to use node.js properly (even for non-typical tasks like sorting) then a performance comparison between node.js and .Net. Even then, I don't think it would be very interesting for people who like to read about node.js. It would be non-news to them, and for an atypical use-case.
I actually have no interest at all in getting a .net stack running on my mac.
The misleading information is what bothers me, so I hope to see it corrected. It's especially harmful because his blog will be most likely read by people who naturally favor .net. It's not even a tech blog per se. Then objective information is all the more important. (EDIT: Actually it does seem to a tech blog, which surprises me a bit, given the superficiality of his analysis)
You can see at the end of his posts, how he diverts from the main subject and goes on about (I'm sure to be) wonderful technologies and possibilities that the .net stack offers.
"I actually have no interest at all in getting a .net stack running on my mac."
How does nodejs performance on windows compare to to OSX or linux?
Parsing floats rather than letting JS loose typing handle it for you kills your sort algorithm: http://jsperf.com/parse-or-no-parse-sort
"<" on strings is lexographic.
As noted elsewhere, lexographic sorting is how the .NET version is doing it.
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:
1. How many threads does the .Net Runtime use?
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.
However, this is not the case for node. One node process will use just one thread(thought it is not the exact fact).
So it's unfair int programming model.
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.
Comparing 'Subject A with one thing that is good at' with 'Subject B with one thing that is bad at'.
Interesting!
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.
It looks like right around 35 parallel request .net reaches the balmer spike. http://xkcd.com/323/
The benchmark should has a new try further, when Asm.js will be added to V8. Sorting arrays of numbers could have another speed.
Can't we all just get along: http://tjanczuk.github.com/edge/#/
On which platform (OS) the NodeJS is running?.
And here I thought perhaps the largest driving force behind node was the ability to use shared code on server and client.
Is there some tech law that states that when someone does a benchmark or comparison, it is almost always incorrect?
There should be.
Microsoft trolling HN? trollface.jpg
This benchmark makes no sense at all. Just a trolling of an official troll.
nice try Microsoft!