Skip to content

[native_assets_builder] Compile and run hooks in parallel #1288

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
dcharkes opened this issue Jul 10, 2024 · 1 comment
Open

[native_assets_builder] Compile and run hooks in parallel #1288

dcharkes opened this issue Jul 10, 2024 · 1 comment
Labels
P2 A bug or feature request we're likely to work on package:hooks_runner

Comments

@dcharkes
Copy link
Collaborator

We should consider:

  • compiling hooks in parallel
  • running hooks in parallel

We should be really optimizing for compile times in dart build / flutter build, e.g. if the package graphs depth is 30 and all of them use hooks, saving a single second (e.g. via parallel compile of hooks to kernel) would save half a minute for a developer.

Originally posted by @mkustermann in #1256 (comment)

The initial prototype was running hooks in parallel, but it locked up someones machine (back then compiling for all targets concurrently). So maybe we should consider limiting the parallelism.

If we intend parallelism to the number of cores on the machine, then we should consider that hooks might use more than one core. Some build systems allow cooperative scheduling:

More conservatively, we could consider only compiling hooks in parallel.

@dcharkes dcharkes added P2 A bug or feature request we're likely to work on package:hooks_runner labels Jul 10, 2024
@dcharkes dcharkes added this to the Native Assets v1.1 milestone Aug 30, 2024
@dcharkes
Copy link
Collaborator Author

We could consider generating an all_hooks.dart wrapper script:

void main(List<String> args) async {
  final package = args[0];
  final hook = args[1];
  switch((package, hook)){
    case ('native_add', 'build'): return native_add_$build.main(args);
    case ('native_add', 'link'): return native_add_$link.main(args);
    /// ...
  }
}

If we go this route, we'd want to compile all hooks in the whole package resolution (not just the dependencies of the current "run package"). Otherwise, running from a different package in the same pub workspace would cause a recompilation.

The downside would be that if there's a compilation error in a hook that's not a dependency, it prevents running things in the workspace.

The assumption here is that many hooks will share the majority of the code. E.g. the standard libraries, the native_assets_cli and possibly other helper packages. It might be that the speedup would be worth it, we'd need to measure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 A bug or feature request we're likely to work on package:hooks_runner
Projects
Status: No status
Development

No branches or pull requests

1 participant