-
Notifications
You must be signed in to change notification settings - Fork 214
Faster shared parts #3803
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
Comments
By "shared parts" do you mean a part file that two libraries both include? If so, is there a requirement for supporting this? The enhanced parts feature removes the ability to share parts in this way, so it's important to know if that isn't going to work. And if not, then we might want to let users know that moving off this pattern sooner will make builds faster, but not actually spend the time to improve performance. |
Sorry, I should have been clearer, I meant the source_gen feature which combines the output of multiple generators. So nothing to do with language/tooling, very much a |
loosely linked to #language-4241 |
Even without automatic part inclusions, enhanced parts would make it possible for each generator to generate a separate part file and then have build_runner generate a single part file that includes all of the generated parts. Users would only be required to add a single |
Good point about enhanced parts, that would be a nice way to do this in the future |
Figured something out here: The shared part builder works by globbing for outputs from all the shared generators
each glob has to check against all inputs, so the number of matches checked is quadratic in the number of inputs. It needs a very big project to notice: 1s for 1000 files, but up to 19s for 5000 files. |
Makes sense, iirc the glob support does have some support for caching globs that are the same and ran in the same phase. So we might be able to do a broader glob like |
Uh oh!
There was an error while loading. Please reload this page.
Using shared parts (edit: the the source_gen feature) currently slows large builds by about a factor of x2; see the benchmark added for #3800 for the data.
The text was updated successfully, but these errors were encountered: