Chapter 3: Is Dart fast enough?

Yes, it is.

...

Alright, look. If I was playing a wise performance guru, I would say something like:

Does it even make sense to talk about the performance of a programming language? Programming languages are abstractions! Only concrete programs, compiled with concrete compilers and executed on concrete hardware, can have a notion of performance.

Then I’d nod to my own wisdom, stroke my long white beard, and close my eyes to meditate on the meaning of “benchmark.”

And I would be correct, of course! We all know that there does not exist a single ranking of programming languages by speed. But I hope we can also agree that, roughly speaking and with a lot of handwaving, that some programming languages are more performant than others.

In most ways that matter, C++ is more performant than Python, for example. Implementing the same algorithm in C++ and in Python will generally lead to a faster program in C++, and a slower one in Python. I bet there are special cases in which Python is, in fact, faster or less resource-intensive than C. But — they’re rare. There’s a reason why real-time simulations are almost exclusively written in C++ and not a more high-level language like Python.

Most people also understand the idea of trade-offs. You can trade a bit of performance for some ease of use, security, portability, or speed of development. And that can obviously be fine because otherwise, if it wasn’t fine, every app ever would be written either in assembly or in C.

If you ever looked into programming language performance, you've probably seen The Computer Language Benchmarks Game.¹ This is a website that has a number of benchmarks implemented in a variety of programming languages, and shows statistics on them in order to “give a simple idea of each language’s general performance”.

From this site you get graphs like these:²

Maybe you've seen them before. The most shallow reading of these graphs tells us this about general programming language performance:

C and C++ and Rust are the fastest programming languages
The following two languages, Chapel and C#, are both about 2x slower than C.
The next cluster of 10 languages is about 3x to 5x slower than C and includes Fortran, Julia, Java, Go and Swift.
The cluster just after that is about 5x to 7x slower and includes OCaml, Dart and Javascript (Node.js).
Racket is next, more than 10x slower than C.
The graph is capped by 7 languages, including PHP (40x slower), Ruby (50x slower), Python (60x) and Lua (90x slower).

But, and this is a big “but”, it’s important to understand what the benchmarks are measuring.

The benchmarks are measuring the elapsed time of long-running computations such as Mandelbrot, Fannkuch or an N-body physics simulation. So, if you’re working on a high performance scientific simulation, for example, then the data above are relevant and yes, in that case you should go with C or Rust rather than Dart.

But if you’re reading this book, chances are you’re either programming apps, servers, or games. And therefore most of your code doesn’t deal with multi-second uninterrupted parallel CPU computations. You’re not computing the digits of π. You’re building UIs and serving data. The benchmarks above don’t really apply then.

For example, let’s say you’re about to write some server-side code and you have a choice between C# and PHP. Looking at the data above, you could get the idea that C# is obviously the better choice, performance-wise. I mean, C# is apparently about 20x faster than PHP, right? How could the data be any more clear?

Yet, in 2022, a blogpost called Yes, PHP Is Faster Than C# made the rounds on the internet, and it made a pretty convincing argument that, at least in reading files (a common task for web servers), PHP is faster than C#. Soon, a C# blogger responded to this with a pretty convincing argument that, no, actually, C# is faster.³ But only for smaller files and only if you know what C# API to avoid, and especially if you know how to do vectorization. That’s a far cry from “C# is 20x faster than PHP”.

My point is not that PHP is faster than C#. It’s not, and measuring simple file access is at least as shallow a benchmark as anything in The Benchmark Game. My point is that the numbers from benchmarks such as The Benchmark Game simply don’t translate neatly to real-world app performance.

There are stabs at better real-world benchmarks out there, though they’re not as well-known as The Benchmark Game. For example, The Programming Language Benchmarks⁴ project measures things like JSON serialization and deserialization, and HTTP servers, and RegEx. Here, Dart tends to be in the middle of the pack, behind Rust and D, comparable to Go and C# and Typescript, and faster than Python, Java, and Kotlin.

But even these benchmarks are far from useful. Because most languages implement things like JSON serialization and HTTP and RegEx internally, in a lower level language. When you parse JSON in JavaScript, for example, the actual parsing is done by code written in C++. So unless your app is a thin wrapper around a JSON parser, and you’re parsing huge JSON files every frame, you don’t care.

Ideally, we’d have something like The Benchmark Game or The Programming Language Benchmarks, but with apps instead of long-running batch jobs. Have a representative set of typical, complex apps. Implement them in C, Rust, Java, Swift, Dart, JavaScript, ideally using a variety of frameworks. Then measure their performance.

But I have a feeling this is never going to happen. There just aren’t enough motivated developers to put the work into implementing so many versions of so many otherwise-useless apps. The programs in The Benchmark Game are all at most a few hundreds of lines of code. That’s just not going to be enough to build complex-enough apps, especially if you’re using something like C or Rust.

The next best thing is to compare game performance, and that’s actually something I did in 2024.⁵ I wanted to compare Flutter, in terms of performance, to the most important game engines out there: Unity and Godot. I designed a simple “game” to exercise the most important muscles a game developer might want in a game engine, such as the ability to track and update many game objects at once.

Flutter (and therefore also Dart) actually did pretty well. Unity is a game engine written in C++ with game logic written in C#. Godot is also a C++ game engine, with game logic written in GDScript (a proprietary programming language similar to Python in syntax but optimized for speed). Again, if you look back at the results from The Benchmark Game, you might assume that Unity and Godot will wipe the floor with Flutter.

I’m not going to repeat all my findings here but, suffice to say, Flutter was actually holding up quite well next to the big boys. It was able to track more than enough game objects without missing frames (more than Godot, in fact) and it was more battery-efficient.

And, not surprisingly, it was several times faster at startup.

So yes, Dart is fast enough. Sure, there are areas in which other languages compare favorably to Dart. But unless you’re doing something very special, you won’t have issues with that. Your bottlenecks are probably going to be somewhere else than in the programming language.

(back to index)