Trying experimental performance work

[davidmorgan]

Forked from #3800, "Discussions" seems a better place for people to add feedback, so let's try it here :)

@gmpassos it will be annoying to try without a flag; a flag will also be useful for me, so I'll look at adding one #3831.

In terms of feedback, performance measurements are actually not particularly useful yet as I still have a lot to do there :) but it would be helpful for people to start checking to see if I actually broke something, i.e. if the new version is incorrect somehow.

Here are dependency overrides that use my PR adding the flag, so if you put this in your pubspec.yaml and pass --use-experimental-resolver when you run build_runner build or build_runner watch then that's the new codepath :)

EDIT: for the latest version, the hash to use in "ref" below is effc827, and there is no --use-experimental-resolver flag. When comparing with the old version, take care to consider both clean and incremental (build, change file, rebuild) as these are very different for performance.

dependency_overrides:
  build:
    git:
      url: https://github.com/dart-lang/build
      path: build
      ref: 6e752db2bb54e2ff043364888e1489883d54eb99
  build_config:
    git:
      url: https://github.com/dart-lang/build
      path: build_config
      ref: 6e752db2bb54e2ff043364888e1489883d54eb99
  build_modules:
    git:
      url: https://github.com/dart-lang/build
      path: build_modules
      ref: 6e752db2bb54e2ff043364888e1489883d54eb99
  build_resolvers:
    git:
      url: https://github.com/dart-lang/build
      path: build_resolvers
      ref: 6e752db2bb54e2ff043364888e1489883d54eb99
  build_runner:
    git:
      url: https://github.com/dart-lang/build
      path: build_runner
      ref: 6e752db2bb54e2ff043364888e1489883d54eb99
  build_runner_core:
    git:
      url: https://github.com/dart-lang/build
      path: build_runner_core
      ref: 6e752db2bb54e2ff043364888e1489883d54eb99
  build_test:
    git:
      url: https://github.com/dart-lang/build
      path: build_test
      ref: 6e752db2bb54e2ff043364888e1489883d54eb99
  build_web_compilers:
    git:
      url: https://github.com/dart-lang/build
      path: build_web_compilers
      ref: 6e752db2bb54e2ff043364888e1489883d54eb99

[davidmorgan]

@gmpassos wrote:

I’ve added your dependency_overrides to our backend project, which requires reflection files to be generated.

NOTE: This is a preliminary benchmark and should not be considered final until all optimizations are fully implemented.

To force a full build, I’m running the following commands on macOS:

• Standard mode:

  dart run build_runner clean && dart run build_runner build --delete-conflicting-outputs

  Executed 5 times:

  [INFO] Running build completed, took 32.5s  
  [INFO] Running build completed, took 32.2s  
  [INFO] Running build completed, took 33.7s  
  [INFO] Running build completed, took 32.6s  
  [INFO] Running build completed, took 32.6s  
  

• Experimental mode:

  dart run build_runner clean && dart run build_runner build --delete-conflicting-outputs --use-experimental-resolver

  Executed 5 times:

  [INFO] Running build completed, took 37.2s  
  [INFO] Running build completed, took 37.2s  
  [INFO] Running build completed, took 37.0s  
  [INFO] Running build completed, took 37.2s  
  [INFO] Running build completed, took 37.6s  
  

[davidmorgan]

Thanks @gmpassos :) ... I do expect to improve initial build time, but for what it's worth, I'm more interested in incremental build time.

Actually the benchmark measures three things: clean build, no changes rebuild, rebuild after changes. And "rebuild after changes" is the most interesting one since that's what people spend most of their time waiting for.

To measure "rebuild after changes" you need to modify a file that's an input of the generator(s), for example put // CACHEBUSTER in lib/app.dart then a script:

#!/bin/bash --

random="$RANDOM$RANDOM$RANDOM"
sed -i -e "s#CACHEBUSTER.*#CACHEBUSTER$random#" lib/app.dart

The incremental build is also more interesting for correctness--it's where bugs are most likely to creep in in the new implementation :)

[gmpassos]

@davidmorgan

For our project, which is a standard backend with routes and a database, the initial build time is almost the same as the incremental build time because the dependency graph for each BuildStep is fully determined by the import tree. Since it's common to modify files shared across many backend modules, a change in a single file typically affects almost all modules.

[gmpassos]

@davidmorgan FYI:

I was investigating where the build process takes the most time.
The first call to BuildStep.inputLibrary takes 18 seconds, while subsequent calls (for each build step) are much faster since they resolve nearly the same code tree.

[davidmorgan]

Thanks--there's no investigation needed at this point though, I have several things to fix that will be big improvements. Then we can check again :)

[amrgetment]

it is failed

[SEVERE] freezed on lib/core/data/models/operation_result.dart:

NoSuchMethodError: Class '_Resource' has no instance getter 'modificationStamp'.
Receiver: Instance of '_Resource'
Tried calling: modificationStamp
dart:core                                                           Object.noSuchMethod
package:build_resolvers/src/analysis_driver_filesystem.dart 185:56  _Resource.noSuchMethod
package:build_resolvers/src/analysis_driver_filesystem.dart 152:7   _Resource.modificationStamp
package:analyzer/source/file_source.dart 66:12                      FileSource.contentsFromFile
package:analyzer/source/file_source.dart 53:12                      FileSource.contents
package:freezed/src/templates/concrete_template.dart 567:25         parseTypeSource
package:freezed/src/templates/properties.dart 79:13                 Property.fromFormalParameter
package:freezed/src/freezed_generator.dart 407:30                   FreezedGenerator._parseConstructorsNeedsGeneration
package:freezed/src/freezed_generator.dart 98:47                    FreezedGenerator.parseDeclaration
package:freezed/src/parse_generator.dart 56:28                      ParserGenerator.generate
package:source_gen/src/builder.dart 342:23                          _generate
dart:async                                                          Stream.toList.<fn>
package:source_gen/src/builder.dart 107:9                           _Builder._generateForLibrary
package:source_gen/src/builder.dart 99:5                            _Builder.build

[davidmorgan]

Thanks @amrgetment :) ... yes, I noticed that one, fixed here: #3835 ... so update your dep overrides to f3d7620091c3c59ff511475274b50ab92c342e8d to pull in that one.

[amrgetment]

I am your beta tester, mention me anytime you want to test

[davidmorgan]

New version build_runner 2.4.15 now published.

No particular difference expected yet, hopefully I didn't break anything :) ... the --use-experimental-resolver flag is there now.

[amrgetment]

@davidmorgan It seems like 2x now
[INFO] Succeeded after 3m 41s with 997 outputs (13915 actions)
that's impressive ❤️

[amrgetment]

with experimental-resolver pr without it same result
dart run build_runner build --delete-conflicting-outputs --use-experimental-resolver
[INFO] Succeeded after 3m 29s with 5161 outputs (12625 actions)

[josh-audio]

Hey @davidmorgan, thanks for your work here. I'm sure I speak for a lot of folks in saying that it's exciting to see work going towards build performance.

Just wanted to add results from my project here, in case they might be helpful. These results come from https://github.com/anthem-audio/anthem/. Some notes about my usage of build:

• I have two purpose-built generators which are both reading all files in lib (see build.yaml) which is around 180 files as of writing, and I also pull in mobx_codegen
• I have around 30 - 40 Dart files that actually trigger output from my generators
• I am outputting just over 30 Dart files, and the same number of C++ files
• One of my generators uses a part builder from source_gen, the other does not

If you want to reproduce these tests, you can clone the repo above, and do the following:

1. Update the package version for build_runner in pubspec.yaml and codegen/pubspec.yaml to the latest
2. Run dart pub get
3. Run dart run build_runner build, or dart run build_runner build --use-experimental-resolver

I am running these tests on Windows 11 / x64.

---

Current resolver

Below are timing results from a few runs, with the current behavior.

Here is the command I'm running:

dart run build_runner build --delete-conflicting-outputs 

I am making trivial edits to lib/model/project.dart to hopefully simulate real-world usage.

And the results:

[INFO] Succeeded after 27.3s with 1158 outputs (2379 actions)
[INFO] Succeeded after 23.3s with 601 outputs (1265 actions)
[INFO] Succeeded after 21.2s with 340 outputs (743 actions)
[INFO] Succeeded after 21.4s with 278 outputs (619 actions)
[INFO] Succeeded after 21.2s with 265 outputs (593 actions)

I find the decreasing actions here interesting, though I haven't paid much attention to this before and it may be normal. I ran a build_runner clean and initial build_runner build before running this test, which may be relevant.

---

Experimental resolver

Here's the command I'm using for the experimental resolver:

dart run build_runner build --use-experimental-resolver --delete-conflicting-outputs

And the results:

[INFO] Succeeded after 22.2s with 260 outputs (583 actions)
[INFO] Succeeded after 21.2s with 260 outputs (583 actions)
[INFO] Succeeded after 21.8s with 260 outputs (583 actions)
[INFO] Succeeded after 22.0s with 260 outputs (583 actions)
[INFO] Succeeded after 21.8s with 260 outputs (583 actions)

[davidmorgan]

Thanks Josh! Good to have another benchmark+check :)

[davidmorgan]

I'd say I'm about 70% of the way through the refactoring needed before I can make real performance improvements :) ... you can see from the stream of PRs what I meant when I said it's complicated ;)

Right now it should actually be a bit slower than before. But still I'd appreciate some test runs please, to check whether I broke anything :) ... the refactoring affects both running with and without --use-experimental-resolver, but there should be no change in functionality and not much change in performance. (Except probably slightly slower).

The latest hash for your pubspec.yaml if you'd like to try it is: 9c3d5f4

Thanks :)

[josh-audio]

Hey @davidmorgan, just validated against your latest merged commit, which is d71fe7d as of writing, using the dependency_overrides as suggested above. All looks good so far 🎉

[davidmorgan]

Great, thanks :)

[davidmorgan]

#3996 is, finally, the refactoring that I've been aiming for this whole time :)

The --use-experimental-resolver flag has gone away, if you use the hash from that PR you're using the new version directly.

I'd be interested to hear how much difference this makes if anyone wants to test it.

There should still be performance improvements coming up, in fact it's possible I made performance worse for some cases; now that the scalability issue is (hopefully) under control I can start to look at where the processing time that remains is going, and to make more targeted improvements.

[amrgetment]

@davidmorgan with commit d63b43b

[INFO] 2m 14s elapsed, 18/19 actions completed.Exhausted heap space, trying to allocate 5012406752 bytes.
[SEVERE] Unhandled build failure!
Out of Memory
dart:core                                                Iterable.iterableToFullString
package:built_collection/src/list/built_list.dart 90:30  BuiltList.toString
dart:core                                                Iterable.iterableToFullString
package:built_collection/src/list/built_list.dart 90:30  BuiltList.toString
dart:core                                                Iterable.iterableToFullString
package:built_collection/src/list/built_list.dart 90:30  BuiltList.toString
dart:core                                                Iterable.iterableToFullString
package:built_collection/src/list/built_list.dart 90:30  BuiltList.toString
dart:core                                                List.toString
package:built_collection/src/list/built_list.dart 90:30  BuiltList.toString
dart:core                                                StringBuffer.write
package:built_value/built_value.dart 356:11              IndentingBuiltValueToStringHelper.add
dart:core                                                List.toString
package:built_collection/src/list/built_list.dart 90:30  BuiltList.toString
dart:core                                                StringBuffer.write
package:built_value/built_value.dart 356:11              IndentingBuiltValueToStringHelper.add
dart:core                                                StringBuffer.writeAll
.                                                        ...
.                                                        ...
dart:core                                                StringBuffer.write
package:built_value/built_value.dart 356:11              IndentingBuiltValueToStringHelper.add
dart:core                                                List.toString
package:built_collection/src/list/built_list.dart 90:30  BuiltList.toString
dart:core                                                StringBuffer.write
package:built_value/built_value.dart 356:11              IndentingBuiltValueToStringHelper.add

[SEVERE] Failed after 23m 57s

[amrgetment]

First time it was 33655605 bytes
I can make a sample repo over the weekend if it can help

[amrgetment]

I think build_runner could use --verbose to print all helpful debugging information

[davidmorgan]

I opened an issue for the OOM #3999 ... let's discuss there?

[amrgetment]

sure

[josh-audio]

Hey @davidmorgan, great to see more progress on this. I'm starting a new thread to report my test results against the latest changes to avoid cluttering the other thread.

I'm testing against 33a0a24.

See above for details on reproducing this test. I am running on the sequencer branch of anthem-audio/anthem, but this should work on the main branch as well. I am using the following steps:

1. Run dart run build_runner clean
2. Add or remove whitespace in lib/model/project.dart
3. Run dart run build_runner build --delete-conflicting-outputs
4. Repeat steps 2 and 3

Before:

[INFO] Succeeded after 18.7s with 428 outputs (1390 actions)
[INFO] Succeeded after 30.0s with 1163 outputs (2396 actions)
[INFO] Succeeded after 21.1s with 607 outputs (1284 actions)
[INFO] Succeeded after 20.6s with 343 outputs (756 actions)
[INFO] Succeeded after 19.9s with 275 outputs (620 actions)

After:

[INFO] Succeeded after 27.6s with 134 outputs (802 actions)
[INFO] Succeeded after 21.0s with 128 outputs (354 actions)
[INFO] Succeeded after 20.6s with 128 outputs (354 actions)
[INFO] Succeeded after 20.0s with 128 outputs (354 actions)
[INFO] Succeeded after 19.5s with 128 outputs (354 actions)

[davidmorgan]

Thanks! Perhaps your project is not suffering from these particular scalability problems, then. There should be more performance improvements coming that will help for projects of any size.

The number of outputs being different across runs is a bit surprising ... if you run with --verbose it will also now print why it's rebuilding or not rebuilding things, which might explain what's going on.

[josh-audio]

I am cleaning before each set of 5, which might explain the first-run spike, and only changing a single file each time I re-run the build. So the first run is a full rebuild, and the second onward are incremental builds.

I can give the --verbose output, if you're still curious. The number of outputs for the prerelease version seems reasonable to me, though perhaps it still shouldn't change between full and incremental builds?

[davidmorgan]

The fix for the OOM found by amrgetment is now merged.

So is adding back write caching, so that files are written at the end of the build, instead of during the build as they are generated, which may help the user experience by causing the IDE to notice the changes all together instead of one by one.

New latest hash :) ed8075f

I'm currently planning to do two things before preparing a release: 1) improve logging so it's clearer where the time is being spent; and 2) some stress testing to see if I can catch any further issues before the release.

[amrgetment]

@davidmorgan
It happened one time only while updating a library in my pubspec.yaml with flutter pub get
Then it works fine, and I cannot reproduce. I cannot see any folder called flutter_gen in my .dart_tool folder
Maybe it is my own app issue, I just reported it because I saw build_runner in the errors
You can ignore it if it is irrelevant

[INFO] Generating build script...Unhandled exception:
Bad state: Unable to generate package graph, no `myapp/.dart_tool/flutter_gen/pubspec.yaml` found.
#0      _pubspecForPath (package:build_runner_core/src/package_graph/package_graph.dart:333:5)
#1      _parsePackageDependencies (package:build_runner_core/src/package_graph/package_graph.dart:307:21)
#2      PackageGraph.forPath (package:build_runner_core/src/package_graph/package_graph.dart:158:33)
<asynchronous suspension>
#3      findBuildScriptOptions (package:build_runner/src/build_script_generate/build_script_generate.dart:99:20)
<asynchronous suspension>
#4      _generateBuildScript (package:build_runner/src/build_script_generate/build_script_generate.dart:35:16)
<asynchronous suspension>
#5      logTimedAsync (package:build_runner_core/src/logging/logging.dart:25:18)
<asynchronous suspension>
#6      generateAndRun (package:build_runner/src/build_script_generate/bootstrap.dart:61:25)
<asynchronous suspension>
#7      main (file:///Users/myuser/.pub-cache/git/build-ed8075fc52e04b4273e7d623b7cb8c0b4354d56b/build_runner/bin/build_runner.dart:105:24)
<asynchronous suspension>

[amrgetment]

Writing the files at the end increases the analyzer's work, so that the IDE will show the errors, then at the end, the analyzer will take time to analyze all the files.
I don't think the files should be deleted, but they should be modified by the required changes only without any deletion so no analyzer errors during the building process

[brian-superlist]

Heya, just some additional data: we've been seeing very long build times since upgrading to build_runner: ^2.4.15. I updated to c7b2fc7 and our build times went from around 5m30s to 47s.

Thanks so much for the big improvement. I'm sure there's more to add, but from my perspective, 🐑 🇮🇹 !

[davidmorgan]

That's great to hear, thanks :)

I found+fixed a couple more bugs today; but I think you're unlikely to see them in practice. Still aiming for release soon, maybe Monday, if I can't find any more bugs :)

[lume-code]

Not sure why I am not seeing the noticeable improvements some mentioned in this topic:
with 2.4.14:

with commit c7b2fc7:

The repository is not public, but if there’s a way to share it privately with a team member, I’d be happy to do so.

[davidmorgan]

Thanks for the measurement.

It's worth measuring both initial builds and incremental builds: i.e. change a file and rebuild. In some cases the incremental builds should have improved a lot more than initial builds.

Whether the changes help, depends on why it's slow: the improvements so far will be mostly for cases where you have very large numbers of Dart source files in the same package transitively imported from generators that do resolution.

I notice you have a very large number of actions on a relatively small number of files (957 outputs, 24908 actions), the logging I'm looking at adding now should be useful here.

[brian-superlist]

Yes, I'd reiterate this is only for incremental builds. Our initial builds are still pretty painful (~5m30s still), but the incremental changes are bearable now. I'd still love to see the initial build speed up.

A few years ago, we found putting all of our mocks into one file and generating from there produced much faster build times. Whenever I change that file I still see the biggest slowdown, so the additional logging (and maybe some way to report the tree back to this repository?) would be of great help for us to understand where our builds are slow and if we could do something to improve them.

[lume-code]

@davidmorgan Thanks for the insight, Yes. for me incremental builds seem somewhat more performant. It takes around 1:30 minutes.

Looking forward to the logging so I will be able to share them.

[Albert221]

Hey! Just providing a benchmark from my side :)

Using the effc827 commit from #3834 (comment), here are my results, in a medium/big-sized production commercial app using plenty of code-generation. Macbook Pro M1 Pro 32GB (with other apps in the background, same in all runs). Flutter 3.29.3.

On the effc827

First build

I've added dependency overrides and ran flutter clean first.

$ time flutter pub run build_runner build -d
Deprecated. Use `dart run` instead.
[INFO] Generating build script completed, took 240ms
[WARNING] Invalidated precompiled build script due to missing asset graph.
[INFO] Precompiling build script... completed, took 445ms
[INFO] Building new asset graph completed, took 892ms
[INFO] Checking for unexpected pre-existing outputs. completed, took 18ms
[INFO] Generating SDK summary completed, took 3.6s
[WARNING] No actions completed for 23.5s, waiting on:
  - json_serializable on lib/<redacted>.dart

[INFO] Running build completed, took 3m 54s
[INFO] Caching finalized dependency graph completed, took 719ms
[INFO] Succeeded after 3m 55s with 2919 outputs (18717 actions)
flutter pub run build_runner build -d  257.48s user 6.40s system 110% cpu 3:59.15 total

Consecutive build

$ time flutter pub run build_runner build   
Deprecated. Use `dart run` instead.
[INFO] Generating build script completed, took 255ms
[INFO] Reading cached asset graph completed, took 619ms
[INFO] Checking for updates since last build completed, took 1.5s
[INFO] Updating asset graph completed, took 3ms
[WARNING] No actions completed for 18.9s, waiting on:
  - json_serializable on lib/<redacted>.dart

[INFO] Running build completed, took 5m 11s
[INFO] Caching finalized dependency graph completed, took 641ms
[INFO] Succeeded after 5m 12s with 2181 outputs (6282 actions)
flutter pub run build_runner build  334.45s user 5.46s system 107% cpu 5:16.99 total

It took much more time. I did not add -d for the second try. Let's try with -d now.

$ time flutter pub run build_runner build -d
Deprecated. Use `dart run` instead.
[INFO] Generating build script completed, took 252ms
[INFO] Reading cached asset graph completed, took 619ms
[INFO] Checking for updates since last build completed, took 936ms
[INFO] Updating asset graph completed, took 3ms
[WARNING] No actions completed for 19.3s, waiting on:
  - json_serializable on lib/<redacted>.dart

[INFO] Running build completed, took 2m 26s
[INFO] Caching finalized dependency graph completed, took 480ms
[INFO] Succeeded after 2m 26s with 0 outputs (0 actions)
[INFO] Running build completed, took 5m 21s
[INFO] Caching finalized dependency graph completed, took 526ms
[INFO] Succeeded after 5m 22s with 2182 outputs (6285 actions)
flutter pub run build_runner build -d  344.15s user 5.67s system 107% cpu 5:26.31 total

Again slower, let's try again:

$ time flutter pub run build_runner build -d
Deprecated. Use `dart run` instead.
[INFO] Generating build script completed, took 249ms
[INFO] Reading cached asset graph completed, took 594ms
[INFO] Checking for updates since last build completed, took 1.6s
[INFO] Updating asset graph completed, took 3ms
[WARNING] No actions completed for 19.2s, waiting on:
  - json_serializable on lib/<redacted>.dart

[INFO] Running build completed, took 5m 8s
[INFO] Caching finalized dependency graph completed, took 621ms
[INFO] Succeeded after 5m 9s with 2182 outputs (6285 actions)
flutter pub run build_runner build -d  331.78s user 5.63s system 107% cpu 5:14.30 total

Slower :/

On "normal" build_runner

lockfile

  build:
    dependency: transitive
    description:
      name: build
      sha256: cef23f1eda9b57566c81e2133d196f8e3df48f244b317368d65c5943d91148f0
      url: "https://pub.dev"
    source: hosted
    version: "2.4.2"
  build_config:
    dependency: transitive
    description:
      name: build_config
      sha256: "4ae2de3e1e67ea270081eaee972e1bd8f027d459f249e0f1186730784c2e7e33"
      url: "https://pub.dev"
    source: hosted
    version: "1.1.2"
  build_daemon:
    dependency: transitive
    description:
      name: build_daemon
      sha256: "79b2aef6ac2ed00046867ed354c88778c9c0f029df8a20fe10b5436826721ef9"
      url: "https://pub.dev"
    source: hosted
    version: "4.0.2"
  build_resolvers:
    dependency: transitive
    description:
      name: build_resolvers
      sha256: b9e4fda21d846e192628e7a4f6deda6888c36b5b69ba02ff291a01fd529140f0
      url: "https://pub.dev"
    source: hosted
    version: "2.4.4"
  build_runner:
    dependency: "direct dev"
    description:
      name: build_runner
      sha256: "058fe9dce1de7d69c4b84fada934df3e0153dd000758c4d65964d0166779aa99"
      url: "https://pub.dev"
    source: hosted
    version: "2.4.15"
  build_runner_core:
    dependency: transitive
    description:
      name: build_runner_core
      sha256: "22e3aa1c80e0ada3722fe5b63fd43d9c8990759d0a2cf489c8c5d7b2bdebc021"
      url: "https://pub.dev"
    source: hosted
    version: "8.0.0"

First build

$ time flutter pub run build_runner build -d
Deprecated. Use `dart run` instead.
[INFO] Generating build script completed, took 260ms
[INFO] Precompiling build script... completed, took 3.2s
[INFO] Building new asset graph completed, took 2.5s
[INFO] Checking for unexpected pre-existing outputs. completed, took 0ms
[INFO] Generating SDK summary completed, took 2.9s
[INFO] Running build completed, took 4m 16s
[INFO] Caching finalized dependency graph completed, took 8.2s
[INFO] Succeeded after 4m 25s with 3218 outputs (19315 actions)
flutter pub run build_runner build -d  312.80s user 20.73s system 121% cpu 4:35.53 total

Consecutive builds

$ time flutter pub run build_runner build -d
Deprecated. Use `dart run` instead.
[INFO] Generating build script completed, took 249ms
[INFO] Reading cached asset graph completed, took 20.9s
[INFO] Checking for updates since last build completed, took 2.0s
[WARNING] No actions completed for 20.4s, waiting on:
  - build_resolvers:transitive_digests on package:lottie/src/providers/network_provider.dart
  - build_resolvers:transitive_digests on package:lottie/src/raw_lottie.dart
  - build_resolvers:transitive_digests on package:lottie/src/providers/file_provider.dart
  - build_resolvers:transitive_digests on package:lottie/src/providers/load_image.dart
  - build_resolvers:transitive_digests on package:lottie/src/lottie_drawable.dart
  .. and 25 more

[INFO] Running build completed, took 5m 53s
[INFO] Caching finalized dependency graph completed, took 7.8s
[INFO] Succeeded after 6m 2s with 4552 outputs (11024 actions)
flutter pub run build_runner build -d  447.72s user 21.85s system 120% cpu 6:29.26 total

$ time flutter pub run build_runner build -d
Deprecated. Use `dart run` instead.
[INFO] Generating build script completed, took 274ms
[INFO] Reading cached asset graph completed, took 23.3s
[INFO] Checking for updates since last build completed, took 2.5s
[WARNING] No actions completed for 21.3s, waiting on:
  - build_resolvers:transitive_digests on package:lottie/src/model/key_path.dart
  - build_resolvers:transitive_digests on package:lottie/src/parser/layer_parser.dart
  - build_resolvers:transitive_digests on package:lottie/src/model/layer/composition_layer.dart
  - build_resolvers:transitive_digests on package:lottie/src/render_lottie.dart
  - build_resolvers:transitive_digests on package:lottie/src/value/lottie_value_callback.dart
  .. and 19 more

[INFO] Running build completed, took 5m 48s
[INFO] Caching finalized dependency graph completed, took 7.5s
[INFO] Succeeded after 5m 56s with 3066 outputs (8052 actions)
flutter pub run build_runner build -d  446.71s user 21.36s system 120% cpu 6:26.87 total

[davidmorgan]

Thanks Albert! Much appreciated.

Let me check if I understood correctly:

• it looks like both initial and consecutive runs are a bit faster with the new version, initial 4m25 -> 3m55, consecutive 6m -> 5m20?
• when you say "it took much more time" you are referring to the consecutive run being slower than the initial run, in both cases?

Indeed it's unfortunate if the consecutive run is slower, this is worth digging into. The logging I'm adding just now should tell us more about what's going on :)

[Albert221]

Happy to help! :) 1. Yes, the build packages from the ref mentioned are a little bit faster in both initial and consecutive builds compared to the "normal" package version. 2. Yes, I don't know how build runner works under the hood, but I'd expect consecutive runs to have some cache built that helps make them faster, not slower