The Performance of Dart 1.3 Is on Par with Node.js

by Abel Avram on Apr 10, 2014 |

The Google Dart team has announced Dart SDK 1.3 which improves the performance of asynchronous server-side code to the point that Dart VM is on par with Node.js, the later using another Google technology, the V8 engine.

Dart has a new performance page plotting the performance of the VM and the dart:io library by measuring the Requests/sec, Avg. Latency and Max Latency of an HTTP server in three cases:

  • Hello - a simple HTTP server responding with the string “world” to all requests.

  • File - an HTTP server returning the content of a 100KB file.

  • JSON - an HTTP server returning a dynamically generated JSON string.

According to the charts, the Dart server now handles more than double the traffic for Hello and JSON scenarios and has a 30% improvement for File requests when compared to Dart 1.2. The Avg. Latency has consequently dropped to less than half for Hello and JSON and by ~30% for File. While in the past the Max Latency fluctuated massively around 125ms and 300ms for Hello and respectively JSON, now this value is quite stable at around 5 and 7 ms.

According to Anders Johnsen, a Google engineer, Dart’s server-side performance was improved by using the generational garbage collector, reducing the number of system calls handling asynchronous I/O on Mac OS and Linux, optimizing the VM compiler and code sections in dart:core and dart:async.

Using a different configuration, TechEmpower benchmarked Dart/nginx in December 2013 doing ~35,000 JSON requests/sec while Node.js did ~70,000 Req/sec. Now that Dart handles more than double JSON requests, we can assume that the Dart VM is on par with Node.js. A future TechEmpower benchmark will probably confirm this. A simple HTTP server built with Google Go beats all frameworks/platform with ~215,000 JSON Req/sec. according to the same benchmark.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Node chokes at high concurrency levels by Greg Lowe

If you look closely at data table of the Techempower plaintext benchmark, you can also see that node chokes at higher concurrency levels, while the DartVM continues responding. It will be interesting to see the results once Dart 1.3 is benchmarked.

Also of note - I find it really impressive that the Dart HTTP server, which is written in Dart, can compete so well against node's Joyent HTTP parser written in optimised C code.

Here are some links showing the data for Dart vs nodejs on the techempower benchmarks:

Plaintext round 8

Plaintext round 9 (Preliminary)

Having said all this - these benchmarks don't really show real world scenarios. Both nodejs' and the DartVM's HTTP servers are fast enough for production use, and not the limiting factor in developing performant web applications.

Re: Node chokes at high concurrency levels by Trevor Norris

[...] can compete so well against node's Joyent HTTP parser written in optimised C code.

Because Dart is definitely out performing optimized C...

The issue is translating the resulting data into a JavaScript object. There are known ways to improve on current performance, but practical application of Node comes first. And for that, the current HTTP parsing speed has so far been sufficient. When it actually proves to be a bottleneck we'll fix it.

Re: Node chokes at high concurrency levels by Mingjian Jin

The main plaintext bench is for measuring the overhead of the IO frameworks in handling IO itself. So, the user logic is tiny in this case.

So, it still reflects some real world scenarios in some extent, like small static file hostings or short message routing(thinking sms/chating in Whatsapp kinds).

And so "fast enough for production use" is not always true as the above mentioned. It is, of course, true if your business processing logic dominates the all the time. In this case, it is not important to choose any framework.

Once you optimize the running of business processing logic into being on par with or even faster than that of IO handling of frameworks. The efficiency of framework matters again.

Finally, I feel interested with the author mention Google Go with Google Dart in the end:) Which language does Google recommend for use in server? Go or Dart?:)

Re: Node chokes at high concurrency levels by Greg Lowe

I totally agree about the current speed being sufficient, and not a bottleneck. (I said this in the original comment ;)

I also didn't claim that Dart's HTTP server out performed optimized C, and I still think it is impressive that the Dart implementation doesn't require a C HTTP parsing library to achieve a similar level of performance as node.

Also topical - using a language with array bounds checks also has security benefits.

Re: Node chokes at high concurrency levels by Greg Lowe

Generally node, or dart's http servers are not used for serving static files in production, typically nginx or apache would take care of this. I don't think the plaintext benchmark is very useful, some of the other benchmarks such as fortunes are probably better for comparing performance under load.

Go and Dart fill different niches, so choices will depend on the use case.

Re: Node chokes at high concurrency levels by Mingjian Jin

:) Instead, I think, it makes less sense to compare these frameworks with benchmarks under much load. because the codes are used to process loads are different. Generally, we just compare apple with orange. Of course, we can improve the libraries which process the load. But who is responsible for this? language runtime? IO framework? web framework? ...

Re: Node chokes at high concurrency levels by Greg Lowe

I think that if a platform can process >10k http requests per seconds at acceptable latencies. Then you've demonstrated that http processing isn't going to be the bottleneck in a web application.

After this threshold (or probably even lower) actual real world performance gains are only obtained in other parts of the stack.

Node is perhaps a good example of this, in the techempower plaintext benchmark it falls over under load at high concurrency levels. But this doesn't actually matter since http isn't the bottleneck, this doesn't cause problems, even when used on high traffic web properties such linkedin, ebay or paypal.

Strong improvements & probably representative for other comparisons by Eyal Alalouf

I have done similar efforts to optimize a web server Framework - optimized Grasshopper ASP.NET engine (co-developed with Mono). From my experience, once we got to similar peformance to Microsoft's ASP.NET engine on the simple use cases (like "Hello world") we were close almost everywhere. The remaining bottlenecks took much less time than this initial breakthrough.
Well done to the Google Dart's team. We now expect you to compare against other frameworks like J2EE, ASP.NET etc. & see the results.

So what's the point? by Richard Eng

So even though Dart's performance isn't competitive with Go's, according to TechEmpower Round 9 (Dart gets 54,896 or 5.2%, while Go gets 348,555 or 33.0%), it doesn't matter because Dart is "fast enough for production use". So why do benchmarks at all? Why care about relative performance? Node.js gets 228,887 or 21.6%, but who cares? Dart is fast enough.

For that matter, Python is fast enough (eg, Tornado-Py3 gets 72,122 or 6.8%). Ruby is fast enough (eg, Rack-Ruby gets 114,466 or 10.8%). All this suggests that performance is not a significant criterion for choosing Dart over other languages.

This entire article is pointless. (Sarcasm.)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

9 Discuss
General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.