| commit | b67895fb98c3c6bbb4e65655797c67842495383c | [log] [tgz] |
|---|---|---|
| author | Googler <brandjon@google.com> | Wed Mar 26 09:18:16 2025 -0700 |
| committer | carmenchui@google.com <carmenchui@google.com> | Thu Apr 03 20:06:49 2025 +0000 |
| tree | a179c51e8f84dec572d452e90ce830be074aa892 | |
| parent | c0dd034180b6e1d0d91497d51c9b537f0965e1bb [diff] |
Reverse a RAM regression introduced by https://github.com/bazelbuild/bazel/commit/7e538803d775929beb3c9af1cd2e87667d373bbe That CL factored some content of `Rule` into a new base class, `RuleOrMacroInstance`. In doing so, it added two new fields to `Rule` instances, causing a 1% RAM regression on a large `query` invocation. This CL eliminates the two extra fields. `attrCount`, the number of attributes in the rule or macro's schema (not to be confused with the number of attributes actually stored on the instance, which may change after freezing/compacting), can be obtained from the schema via the subclass's `ruleClass` or `macroClass` field without storing it as an additional field on the base class. We have to take care not to do this retrieval of the subclass field while executing the super constructor (i.e. before the subclass field is initialized). That's solved by threading `attrCount` into `bitSetSize` as a parameter. (A prior draft of this CL went through some indirect initialization logic whereby the super constructor called an abstract method to initialized the subclass field. Thanks to arostovtsev@ for pointing out that this was unnecessary.) The second field, `packageDeclarations`, is replaced by an abstract getter that already exists on `Rule` and which is added to `MacroInstance` in this CL. It's probably not really needed on `MacroInstance`, but we can eliminate that latter; the cost of an extra field on a macro is nothing like the cost of an extra field on a rule. PiperOrigin-RevId: 740793903 Change-Id: Iec65f20ff459e33c3961b16d9d51d0d4a22f0e00
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.
See CONTRIBUTING.md
