[tinco]

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.

[bagosm]

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

[jeswin]

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.

[bagosm]

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)

[bmuon]

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

[jeswin]

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

[bmuon]

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

[bagosm]

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

[virmundi]

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.

[trust-me]

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.

[virmundi]

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.