| commit | fecf56f1c28a774d2bc2ccf2a94c7b687ad3baba | [log] [tgz] |
|---|---|---|
| author | nharmata <nharmata@google.com> | Tue Dec 15 06:47:26 2020 -0800 |
| committer | Copybara-Service <copybara-worker@google.com> | Tue Dec 15 06:48:50 2020 -0800 |
| tree | 16596d1e20f6542c61c0dea14574682dc3f05392 | |
| parent | 3551898849a93306ad9b4dfdd7d4667913098efe [diff] |
bazel package loading: Cache, intra-package, `String` -> `Label` conversions during BUILD file evaluation. For some packages, `LabelType#convert` is a CPU hotspot during BUILD file evaluation, and so the approach in this CL can be a pretty big performance improvement. (I *do* have a plan in mind to address that, but in practice I think this CL here will get rid of the hotspot.) It's common for there to be duplicate label-strings encountered during evaluation of a single BUILD file. Consider ``` # blah/BUILD java_library(name = 'a', srcs = ['A.java'], deps = ['//other:a', '//common:dep']) java_library(name = 'b', srcs = ['B.java'], deps = ['//other:b', '//common:dep']) ``` In this case, we'll do the Starlark-land-String -> Bazel-land-Label conversion for "//common:dep" twice. `Label#LABEL_INTERNER` *is* useful for reducing duplicate retained objects, but we still have to wastefully construct the duplicate `Label` object (paying both the CPU, notably `Label#validateTargetName`, and GC churn costs), and then the CPU + contention cost of the `MapMakerInternalMap` lookup. Instead, by having a package-local cache in front of `Label#LABEL_INTERNER`, we avoid all of this. Therefore, for many BUILD files, this CL here reduces both CPU time and wall time, and also nicely reduces the total number of allocated bytes (even though are introducing a new data structure!). In some "loading phase" benchmarks of internal Google targets at various points in the BUILD-land-spectrum, this change reduces wall time by between 5% and 50%, and total number of allocated bytes by between 1% and 36%. PiperOrigin-RevId: 347602162
{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:
See CONTRIBUTING.md
