For those who haven’t noticed yet — as Kevmoo announced here — build_runner ^2.5.0 includes the first round of performance improvements.
In our case, I see a 10x speed-up when running with existing generated files, and a 2x speed-up for clean builds. I shared a comparison here — we went from 105 seconds down to 12 seconds on an M1 Mac. Huge improvement!
6 Likes
I didn’t even notice that the output totally changed O.o
1s graphql_codegen on 2 inputs: 2 same
18s dart_mappable_builder on 52 inputs: 3 output, 49 no-op; spent 12s analyzing, 3s sdk, 2s resolving
Built with build_runner in 20s; wrote 5 outputs.
log output for build_runner
Deleting 5 declared outputs which already existed on disk.
Still, 20s is A LOT of time =\ I wish the Dart team could replicate C# macros (called Source Generators). Introducing C# Source Generators - .NET Blog They are fast. Like, really, fast (as Dart can be).
What I noticed in the output above is that graphql_codegen
only takes 1s. Don’t know exactly how… that is giving me some ideas… back in the old .net framework days, we had T4 (Text Template Transformation Toolkit). Basically a script like ASP or PHP that used C# to generate C#. It run fast. So, if graphql_codegen
is fast because it is only dealing with one .gql file, maybe, something like dart_mappable
could be achieved by declaring a class using yaml instead of Dart… I’ll try that someday…
2 Likes