Skip to content
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

[7.0.0] Fix analysis time regression with Bzlmod lockfile #20021

Merged
merged 1 commit into from
Nov 2, 2023

Conversation

bazel-io
Copy link
Member

@bazel-io bazel-io commented Nov 2, 2023

This commit fixes a regression in analysis time caused by 19c0c80. Since BazelModuleResolutionEvent and ModuleExtensionResolutionEvent are both marked as storeForReplay, they are stored in a nested set for essentially all analysis phase nodes. This resulted in frequent (i.e., per target) calls to their hashCode methods, which are not cached and delegated to the likewise uncached methods on large ImmutableMap and ImmutableTable instances.

Since there is no need for these events to be deduplicated, switching to reference equality resolves this issue.

The following analysis phase measurements for a synthetic project with a single "hub and spokes" module extension and 2,000 repos illustrate the effect:

  • without lockfile: 4.3s
  • with lockfile before this commit: 8.3s
  • with lockfile after this commit: 4.2s

Fixes #19952

Closes #19970.

Commit 435d1c2

PiperOrigin-RevId: 578734010
Change-Id: I870867c5c509389632793b0d5fe5c43ddc6176f3

This commit fixes a regression in analysis time caused by 19c0c80. Since `BazelModuleResolutionEvent` and `ModuleExtensionResolutionEvent` are both marked as `storeForReplay`, they are stored in a nested set for essentially all analysis phase nodes. This resulted in frequent (i.e., per target) calls to their `hashCode` methods, which are not cached and delegated to the likewise uncached methods on large `ImmutableMap` and `ImmutableTable` instances.

Since there is no need for these events to be deduplicated, switching to reference equality resolves this issue.

The following analysis phase measurements for a synthetic project with a single "hub and spokes" module extension and 2,000 repos illustrate the effect:

* without lockfile: 4.3s
* with lockfile before this commit: 8.3s
* with lockfile after this commit: 4.2s

Fixes bazelbuild#19952

Closes bazelbuild#19970.

PiperOrigin-RevId: 578734010
Change-Id: I870867c5c509389632793b0d5fe5c43ddc6176f3
@bazel-io bazel-io requested a review from a team as a code owner November 2, 2023 04:40
@bazel-io bazel-io added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. awaiting-review PR is awaiting review from an assigned reviewer labels Nov 2, 2023
@iancha1992 iancha1992 enabled auto-merge (squash) November 2, 2023 05:21
@iancha1992 iancha1992 merged commit 8f44ab7 into bazelbuild:release-7.0.0 Nov 2, 2023
@github-actions github-actions bot removed the awaiting-review PR is awaiting review from an assigned reviewer label Nov 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants