Live data from Hacker News

.NET and Node.JS – Performance Comparison

salmanq.com

31–40 of 119 posts

Re: .NET and Node.JS – Performance Comparison

#31
post #13

Earlier quoted context omitted.

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 gra…

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.

Re: .NET and Node.JS – Performance Comparison

#32
post #13

Earlier quoted context omitted.

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 gra…

[deleted]

Re: .NET and Node.JS – Performance Comparison

#33
post #22

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

Re: .NET and Node.JS – Performance Comparison

#35

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.

Re: .NET and Node.JS – Performance Comparison

#36

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.

Re: .NET and Node.JS – Performance Comparison

#37

Earlier quoted context omitted.

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.

Re: .NET and Node.JS – Performance Comparison

#38
post #26
post #20

Earlier quoted context omitted.

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 imp…

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 no…

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.

Re: .NET and Node.JS – Performance Comparison

#39

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.

Re: .NET and Node.JS – Performance Comparison

#40

Earlier quoted context omitted.

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)

Post reply on HN