-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Don't call Starlark implicit outputs functions twice
Previously, a Starlark rule's implicit outputs function would be called twice: once during loading to help populate the complete set of outputs, and then again at the start of analysis while constructing the `ctx.outputs` object. This double Starlark evaluation was not only wasteful, but caused StarlarkRuleContext's constructor to potentially throw EvalException and InterruptedException, complicating refactoring of that code. This change makes it so we remember the result of the first call in Rule and access it later. Initial versions of this CL attempted to store the implicit output function results in a new field on Rule. However, this added ~0.5% RAM overhead to a large `build --nobuild` invocation, and ~1.5% on a `query 'deps(...)'` of the same target. (This increase was not attributable simply to the addition of the field itself, but to the map entries it contained.) The new strategy is to take an existing field that held all the outputs (implicit and explicit), and expand it to also include the string keys of Starlark implicit outputs. Not only does this avoid adding new redundant fields, it allows us to contract an existing one. The tradeoff is that the accessors must do some computational work to copy only the relevant data from the field. The stored map is compressed as a flat list for further space savings. Along the way, I refactored the code that populates this collection of outputs. The diff is larger than I would've liked, but essentially the bodies of populateExplicitOutputFiles() and populateImplicitOutputFiles() got lifted into lambdas in the caller (with a little inlining of helpers), to better update state during the computation. There may be further refactoring that could be done, e.g. changing the mode of one failure to do a rule error instead of a LabelSyntaxException, or combining validation logic into one place, but I'm trying to avoid any more semantic changes than are absolutely necessary. On the benchmark alluded to above, we save 0.93% RAM on a query invocation, and 0.40% on a build --nobuild. Cleanup work toward #11437. PiperOrigin-RevId: 354631199
- Loading branch information
1 parent
1ab1a3a
commit d258263
Showing
7 changed files
with
294 additions
and
178 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.