I’ve been working on a book about Flutter & Dart performance. I’m at the very beginning, with only a few chapters drafted but I decided to write the book in the open.
Here it is:
Looking forward to feedback and suggestions!
23 Likes
Alright, look. Dart is not the most performant programming language out there.
One thing that blew my mind a long time ago when I tried to compare C# with Dart for backend stuff: Dart consumes sooooooo little RAM.
Funny enough, I never read this amazing Dart feature written anywhere, especially when we’re dealing with devices that have a very limited amount of it (in 3rd world countries, 3Gb RAM Androids are still the norm), which I don’t think it is a coincidence at all.
2 Likes
On another topic:
- C and C++ and Rust are the fastest programming languages
I onced worked on a Stock Trade IT company. They had this mindset that things in ST should be fast and C++ should be used.
One day, I had nothing to do, so I get a C++ code that calculated some stock option security codes (something like the credit card number validation) and comparing with C# (which was my preferred language at that time), just to check how much C++ would destroy C#.
The final code was almost the same: without checking the C++ code, I wrote the same solution. Except my C# code was 140x faster than C++.
Asking the C++ team leader (which was a hell of a C++ programmer, a very competent professional and well known in his area), he said: yeah, you could optimize it so it would run a lot faster, using this library or doing that stuff. It is just not optimized.
From that day I never compared languages again: they are like a F1 car. I can drive a car. I would probably would crash or lose a race for a VW Bettle if I drive one of those so, what’s the point anyway?
Same goes for Flutter: 7 years ago when I wrote my first app, it was pure garbage. “Flutter is slow”. The truth is: my code was a mess, it was not only not optimized, but plain wrong (I just didn’t understood Flutter at the time). You don’t really need to optimize, but you really should know what you are doing. The language “speedness” means nothing (especially for AoT).
3 Likes
Good point. That part is very hand-wavy because I just kind of need to get it out of the way. I should probably be more clear that there’s no “fast programming language”, there’s only “fast program”. Programming lanugage is an abstraction. Only a concrete program running in a concrete environment (architecture, RAM, etc.) can be fast or slow.
That said, I also didn’t want to be too theoretical and highfalutin about it. Yes, C# can be faster than C++. But in most ways that matter, it isn’t. Same way, Dart can be more performant than C++ or less performant than Ruby. But in most ways that matter, it isn’t.
From there, I was hoping to be able to move on to the more practical questions, such as “how do I get my program to be efficient / fast / etc.”
4 Likes
What you just wrote clarified everything for me 
Can’t wait to read more, super excited about it.
One topic that I’m particularly interested is assessing the performance of large/medium scale applications. The ones where many things are happening at the same time, where you can observe some jank or performance drops, but it’s difficult to pinpoint what’s the actual reason.
In fact that’s what I’m dealing with right now: app with few SQLite databases, dozens of isolates, multiple network requests and websockets, bluetooth data streaming over method channel, over-scaled images, manually drawn charts of minute-by-minute data. On a good day it still behaves exceptionally well (which is amazing), but there are cases where it’s just collapsing. When trying to analyze what’s the main reason you don’t even know where to start, and once you start eliminating things one by one, the performance problems no longer occur as if they were only a result of many things interacting with each other. So isolation to a single performance bottleneck is somewhat impossible. The devtool performance charts are just useless in that case as so many things happen concurrently.
I’d like to read what would be your take in such case, how not to lose your mind when trying to assess and fix the performance in a very noisy environment.
2 Likes
Thanks!
First things first: I think that the book will have to limit its scope only to Dart & Flutter. So whatever happens outside (i.e. the other side of method channels and FFI) is going to be out of scope. I may have a chapter about “putting it all together”, mentioning things like Xcode perf tools, but that will necessarily be very shallow because that topic alone could be a separate book or two.
With that out of the way, I have two questions for you:
- Can you (at least somewhat-) dependably reproduce the collapse? Like, is there a way to stress-test the app from within the app? Something like “ok, now make N requests and at the same time navigate to and from these highly complex pages”. Obviously, the less you need to recreate the issue, the better it will be to analyze.
- Have you considered looking at the CPU profile (not timeline) during such high loads? Maybe it’ll at least give you pointers where the majority of that time is spent.
Yes, I have ways to for instance add hundreds of new items in the last n days and can observe how the database queries and network requests just freeze the app even in release. Or when I do a lot of panning and zooming on my chart I can see that it skips frames.
Have you considered looking at the CPU profile…
That’s a good call, but the problem I’m seeing is that a lot of the referenced methods is quite generic to Flutter/Dart. I may post some screenshots later, but I don’t want to derail the thread 
For native remarks I think it may be worth mentioning Xcode’s Organizer showing e.g. large scale battery usage, disk writes, network etc.
2 Likes
I feel your pain… Using the wonderful Drift (not an) ORM with the isolate option and some screens was way too slow. Took me days to realize that it was not it at all O.o
The culprit was Emojis. Flutter iOS has a terrible performance problem with emojis (just try to use https://fonts.google.com/noto/specimen/Noto+Color+Emoji?query=emoji. It takes literally seconds to display each emoji on screen (using it as a standard custom font, like any other)). Later, checking GitHub issues, I found that this font used two systems: one not supported by iOS and other being SVG (which is very slow), hence, the (very) terrible rendering performance.
Reverting to standard iOS emojis “solved” the problem, but the screen still stutters when animating in (and the only thing I was doing at the moment was querying a database, hence my confusion).
Now, in your case, imagine the pain in figuring out why things are slow with so much going on O.o
3 Likes
Thank you, this is very helpful. I am seeking permission to reproduce certain portions of your content in my upcoming article.
Thanks for asking! Be my guest!
For what it’s worth, I don’t think you need permission to quote from published content (as long as it’s not huge section, of course) but it’s nice of you to ask.
Once you publish the article, please don’t hesitate to share it here.
2 Likes
Thanks @filip
What’s going to be the best way to follow this project for updates?
1 Like
Definitely https://filiph.net/await. That’s a mailing list that I update something like once a year, and if you subscribe to the Flutter topic, I’ll definitely send an update if and when the book’s available.
If you mean continuous updates, then I don’t have a good answer but there are options:
- I’m thinking of using this very thread as a sort of “devlog” for the book.
- The book has an RSS feed here: https://filiph.net/flutter-performance/atom.xml
- I’ll probably be giving updates on my social media (e.g. Mastodon) and on Discord (links here)
1 Like
While I’m at it, here’s my first update:
- I’m planning to first write the book out in drafts, and only then coming back and editing. (Otherwise, I’d never get to finishing it.) So if you don’t see me correcting some blatant mistakes in a draft, know that I’m planning to get to it sooner or later.
- Since the time I posted this thread:
- I slightly adjusted the outline
- I finished the chapter 2 draft: Chapter 2: Performance, speed, efficiency
- I finished and corrected chapter 4 draft: Chapter 4: Amdahl’s law
- I started chapter 5: Chapter 5: Performance lottery (not finished yet)
- I got good feedback on Chapter 3: Is Dart fast enough? (but haven’t implemented any changes yet)
2 Likes
Thank you so much ! Can’t wait to read this.
1 Like
A small update from me:
- Finished Chapter 5: Performance lottery
- Started a stub of Chapter 6: Environment
6 Likes
The RSS feed seems to be pointing to a 404 page.
The link from RSS is https://filiph.net/text/010-intro.html whereas the link for the same chapter is in Chapter 1: Intro
1 Like
Thanks for the report! This should be fixed now.
1 Like