4 ms·

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 y

by tinco 14y ago

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 14y ago
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 14y ago
  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 14y ago
    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)
    - virmundi 14y ago
      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 14y ago
        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 14y ago
        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.
        14y ago

by tinco 14y ago

bagosm 14y ago

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 14y ago
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 14y ago
  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)
  - virmundi 14y ago
    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 14y ago
      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 14y ago
        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.
        14y ago