TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

.NET and Node.JS – Performance Comparison

123 点作者 bencxr大约 12 年前

33 条评论

pilif大约 12 年前
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.
评论 #5461357 未加载
评论 #5461139 未加载
评论 #5461262 未加载
评论 #5461065 未加载
chjj大约 12 年前
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>&#62; 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.
评论 #5460236 未加载
eknkc大约 12 年前
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.
评论 #5460392 未加载
jrajav大约 12 年前
.NET native list sorting and Node.JS async.sortBy - Performance Comparison<p>Fixed that for ya.
评论 #5460267 未加载
评论 #5460447 未加载
dexen大约 12 年前
The author notes about himself:<p><i>&#62; 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> )
评论 #5460742 未加载
评论 #5460171 未加载
评论 #5460180 未加载
评论 #5460172 未加载
d4nt大约 12 年前
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.
评论 #5460923 未加载
评论 #5460443 未加载
tinco大约 12 年前
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.
评论 #5460139 未加载
antihero大约 12 年前
Until Mono becomes 100% supportable, <i>none</i> of the advantages of .NET outweigh the misery of having to use Windows for development and serving.
评论 #5460299 未加载
评论 #5460987 未加载
评论 #5461196 未加载
评论 #5460836 未加载
评论 #5460304 未加载
评论 #5461013 未加载
评论 #5461025 未加载
manojlds大约 12 年前
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 :)
评论 #5460286 未加载
Wintamute大约 12 年前
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.
评论 #5460275 未加载
评论 #5460978 未加载
quarterto大约 12 年前
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).
评论 #5460205 未加载
jroseattle大约 12 年前
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.
davidjhamp大约 12 年前
Javascript is slower at sorting numbers then .Net!<p><i>mind blown</i>
nicwise大约 12 年前
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)
benmmurphy大约 12 年前
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.
jeswin大约 12 年前
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.
meryn大约 12 年前
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?
评论 #5460976 未加载
评论 #5461790 未加载
评论 #5460442 未加载
评论 #5461605 未加载
评论 #5460919 未加载
评论 #5460822 未加载
octatone2大约 12 年前
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>
评论 #5460730 未加载
tempoman大约 12 年前
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.
richyzhang大约 12 年前
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?
meryn大约 12 年前
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.
nabaraj大约 12 年前
Comparing 'Subject A with one thing that is good at' with 'Subject B with one thing that is bad at'.<p>Interesting!
malachismith大约 12 年前
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.
jasallen大约 12 年前
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.
brenfrow大约 12 年前
It looks like right around 35 parallel request .net reaches the balmer spike. <a href="http://xkcd.com/323/" rel="nofollow">http://xkcd.com/323/</a>
scriptproof大约 12 年前
The benchmark should has a new try further, when Asm.js will be added to V8. Sorting arrays of numbers could have another speed.
htilford大约 12 年前
Can't we all just get along: <a href="http://tjanczuk.github.com/edge/#/" rel="nofollow">http://tjanczuk.github.com/edge/#/</a>
suhair大约 12 年前
On which platform (OS) the NodeJS is running?.
Glyptodon大约 12 年前
And here I thought perhaps the largest driving force behind node was the ability to use shared code on server and client.
rrouse大约 12 年前
Is there some tech law that states that when someone does a benchmark or comparison, it is almost always incorrect?<p>There should be.
hallomac2013大约 12 年前
Microsoft trolling HN? trollface.jpg
sdogruyol大约 12 年前
This benchmark makes no sense at all. Just a trolling of an official troll.
omniwired大约 12 年前
nice try Microsoft!