Allow native.existing_rule and native.existing_rules to return a lightweight view.

Experimental implementation of
https://github.com/bazelbuild/proposals/blob/main/designs/2021-06-15-improving-native.existing_rules.md

Gated behind the --experimental_existing_rules_immutable_view flag. See
https://github.com/bazelbuild/bazel/issues/13907

To check the performance impact, I queried a toy package that in a loop, creates
a genrule and then on each loop iteration performs one of the following tasks:

* checks if rule with a given name existed in `existing_rules()` ("in")
* for each rule in `existing_rules()`, checks if an attribute with a given name exists ("shallow iteration")
* for 50% of rules in `existing_rules()`, checks if a particular attribute value exists under any name ("50% deep iteration");
* iterates every rule name, attribute name, and attribute value ("deep iteration");

Query time in seconds without --experimental_existing_rules_immutable_view:

```
n	in	shallow 50%deep	deep
1000	2.73	2.84	3.36	3.61
2000	8.42	9.07	10.97	11.62
4000	30.95	33.81	40.88	44.17
```

With --experimental_existing_rules_immutable_view:

```
n	in	shallow 50%deep	deep
1000	0.40	0.64	2.58	4.19
2000	0.43	1.08	7.96	13.64
4000	0.51	2.59	28.83	52.99
```

In other words, in the unusual case where we examine every attribute value
of every existing rule, the overhead of managing immutable views would cause
a 15-20% slowdown. In any other situation, where we don't need to materialize
every rule's attribute values, the immutable view approach yields a
substantial performance improvement.

We'd want to see if we can reduce the 15-20% worst-case penalty in followup
work.

RELNOTES: Adds --experimental_existing_rules_immutable_view flag to make the
native.existing_rule and native.existing_rules functions more efficient by
returning immutable, lightweight dict-like view objects instead of mutable
dicts.
PiperOrigin-RevId: 397805096
10 files changed
tree: 3475bc7fedbd2ebae97e54c6bbaa7b050b5e10ef
  1. .bazelci/
  2. examples/
  3. scripts/
  4. site/
  5. src/
  6. third_party/
  7. tools/
  8. .bazelrc
  9. .gitattributes
  10. .gitignore
  11. AUTHORS
  12. BUILD
  13. CHANGELOG.md
  14. CODE_OF_CONDUCT.md
  15. CODEBASE.md
  16. CODEOWNERS
  17. combine_distfiles.py
  18. combine_distfiles_to_tar.sh
  19. compile.sh
  20. CONTRIBUTING.md
  21. CONTRIBUTORS
  22. distdir.bzl
  23. distdir_deps.bzl
  24. ISSUE_TEMPLATE.md
  25. LICENSE
  26. README.md
  27. SECURITY.md
  28. WORKSPACE
README.md

Bazel

{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.

Getting Started

Documentation

Reporting a Vulnerability

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.

Contributing to Bazel

See CONTRIBUTING.md

Build status