Analyzing build_runner perfomance logs

[BuyMyBeard]

Hello! I develop on the daily a SAAS app built with flutter. Lately, my build times have been getting awful (~30-45s). I have build_runner generating json_serializable and freezed models, and also some routes with go_router_builder.

I noticed today that if I run build_runner build with args --build-filter="lib/models/**", the build time gets cut to about 5s, but if I instead do --build-filter="lib/routes/**", the build time is a whopping 25-30s!

I want to diagnose the problem so I can go about fixing my own setup / contribute to go_router_builder, but I'm pretty lost here. I managed to launch the debug into build_runner with ".dart_tool/build/entrypoint/build.dart", and also use --track-perfomance --log-perfomance=logs, But the generated log file is a whopping 127 megabytes, and no freeware json-viewer can handle this.

What would be the best approach here to diagnose the problem?

[davidmorgan]

Hi :)

I've been staring at these performance logs for a couple of weeks now, and one thing is clear: build_runner has a scalability issue around number of transitive deps of the files generators run on. So it's possible that the performance problems you are seeing are not in go_router_builder, but are in build_runner itself. Then, the work that I'm currently doing #3811 will help :)

But problems with specific generators are also possible; and a third possibility is that the output is slow to format, built_value had a problem with slow formatting until recently.

So, profiling to check:

Once you have a build script you can get a profile by running something like

dart --observe=26199 --sample-buffer-duration=300 --pause_isolates_on_start .dart_tool/build/entrypoint/build.dart build -d

then going to the URL it prints in your browser, going to the "CPU profile" tab, hitting record, then unpausing the isolate.

If nothing in go_router_builder, freezed or dart_style is high on the list then the problem is build_runner itself :)

[BuyMyBeard]

dart_devtools_2025-02-07_11_19_36.050.json
These are my results. I am not 100% sure how to interpret them, but I've simply found it weird that volume-wise, go_router_builder takes that much more time to build compared to freezed, when freezed has to analyze about 45 different files while go_router_builder analyzes a single file with about 35 TypedGoRoutes.

[davidmorgan]

Thanks.

I'm not seeing anything much in the profile from either generator: the first go_router_builder method I see in "Method Table" sorted by "Total %" is RouteBaseConfig.parent at only 1.63%.

So it looks like most of the time is spent in build_runner and the analyzer.

Is it possible that the difference in time between lib/models/** and lib/routes/** is simply because "routes" has more transitive imports? If routes depends on more code then that will certainly take longer to analyze, and right now it also slows down build_runner.

[BuyMyBeard]

I guess that would make sense. my top_routes file containing all my annotations imports 2 major library files, and since our codebase uses part / part of instructions, about 100-150 total files have to be analyzed. I was pushing my team to move out of library directives. That would be another argument in favor of it.

[BuyMyBeard]

In hindsight, I think almost every file in the codebase has to be loaded as a transitive dependency if the routes need to import their own built widget. So I guess that's pretty much unavoidable as the codebase scales. At the moment I think ours is around 30k-50k lines of dart.

Im putting my hopes up you deliver on optimizing the scalability of build_runner :)

[davidmorgan]

Yes, there are likely cases where it's just natural for codegen output to depend on everything. I think addressing the issue in build_runner is the right fix. Let's see :) thanks.

[jakemac53]

@BuyMyBeard Fwiw see this doc on filtering which files a given generator runs on as well, if you haven't already done that.

It won't fundamentally fix the problem but it can alleviate some of the issues if you ensure the builders aren't running on more files than they need to.

[BuyMyBeard]

Is there any difference between using this and --build-filter? It seems about the same to me.

[jakemac53]

It has the same effect as build-filter essentially yes but it will happen for all builds so its reliable/consistent. It will also result in a smaller asset graph (with build-filter the build system still knows about all the other actions and has nodes for them)

[tatumizer]

All these "transitive dependency" issues are associated with the particular execution model used by the build runner, where the annotations control the execution.
I am thinking of a different, much simpler, model based on build-time reflection.

1. Compiler fully compiles the application
2. dart function build_main gets executed, which controls (programmatically) the execution of build functions in all modules (whose dependencies are configured in the corresponding projects)

With this model, there's a clear separation between the compiler and the build process.
This can achieve a lot more than we currently can with any of the approaches discussed before.
E.g. you can generate glue code, wrappers, etc, for existing classes, by selecting the set of classes of interest via reflection, and generating whatever you want on top of them.

This requires the restoration of mirrors, including the ability to execute code from sub-modules. (This eliminates the problem of const functions - this method doesn't need them)

This is the simplest approach I can think of. I'm not sure the idea was explored before.

(Using annotations as a driver for execution is inconvenient anyway: if you have N data classes for which you want to generate some FancySerializer, you can say for (clazz in [A, B, C, etc]) generateFancySerializer(clazz); rather than going into each class and annotating it individually. You can comment this line out while debugging other things.)

[davidmorgan]

All these "transitive dependency" issues are associated with the particular execution model used by the build runner, where the annotations control the execution. I am thinking of a different, much simpler, model based on build-time reflection.

No need to change the whole model--they can be fixed with internal refactoring of build_runner. It's just that it's complicated. Work in progress :) and well under way...