Skip to content

build: non-root toolchain registration loads go_toolchains and rules_py constraint packages on every command (upstream) #9203

Open

Description

@TrapsterDK

Part of #8912. Found while profiling analysis of //cli/process/... on linux_x86_64 (origin/main 5cea169).

Toolchain registration from non-root modules loads packages that the scope never uses. The largest package creation spans after @rules_dotnet//dotnet are:

package package creation (s, loaded machine) registered by
@@llvm+//toolchain 0.72 root (@llvm//toolchain:all)
@@rules_go++go_sdk+go_toolchains// 0.59 rules_go (non-root)
@@rules_py+//uv/private/constraints/platform 0.51 rules_py (non-root)
@@rules_python+//python/config_settings 0.17 rules_python

In the Starlark CPU profile, declare_bazel_toolchains (go_toolchains) is 0.12s and generate_macos (rules_py uv constraints) 0.12s. Non-root register_toolchains cannot be removed from the root module, so this needs upstream changes.

Where

  • rules_go go/private/sdk.bzl / go_toolchains repo, rules_py uv/private/constraints/platform.

Fix

  1. File upstream issues on bazel-contrib/rules_go and aspect-build/rules_py asking for lighter registered-toolchain packages (fewer generated config_settings, or registration that does not need these packages).
  2. No change in rules_dx until upstream lands; then measure with two evidence pairs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Xut2hzpb4qWNZKpDCrwUz7

Activity

  1. added
    P2Improve and finish existing features
    model:sonnetAgent lane: scoped change with stated design, Sonnet
    on Nov 7, 2026
  2. TrapsterDK commented on Nov 7, 2026

    @TrapsterDK
    CollaboratorAuthor

    Upstream issues filed: bazel-contrib/rules_go#4779 (go_toolchains package) and aspect-build/rules_py#1675 (uv/private/constraints/platform). No rules_dx change until they land.

    🤖 Generated with Claude Code

    https://claude.ai/code/session_01Xut2hzpb4qWNZKpDCrwUz7

  3. added
    blockedWaiting on upstream or a design decision
    and removed
    model:sonnetAgent lane: scoped change with stated design, Sonnet
    on Nov 7, 2026
  4. github-actions commented on Nov 7, 2026

    @github-actions

    This issue has the blocked label but no Blocked on: line in its body. Add one naming the blocking issue (#N), a pull request URL, or the owner action. See CONTRIBUTING.md.

  5. TrapsterDK commented on Nov 7, 2026

    @TrapsterDK
    CollaboratorAuthor

    Round 9 result (#9203, PR #9303): the rules_go root_sdks_only patch and the rules_py platform_flags_package patch. They do what they should, but Windows is much slower, so this is dropped. PR #9303 is closed.

    Scope //cli/process/..., task=test, linux_x86_64 and windows_x86_64. All four runs started at the same time and all passed. Branch head 62ea925.

    • Pair 1: main 42374830074, branch 42374831990
    • Pair 2: main 42374833810, branch 42374835892

    setup-bazel + "Run evidence task" step (s)

    platform main p1, p2 branch p1, p2 main median branch median delta
    windows_x86_64 40, 36 55, 56 38.0 55.5 +17.5
    linux_x86_64 35, 37 34, 30 36.0 32.0 -4.0

    Bazel elapsed for the evidence task (s)

    platform main p1, p2 branch p1, p2 main median branch median delta
    windows_x86_64 34.8, 31.8 48.5, 51.2 33.3 49.8 +16.5
    linux_x86_64 30.3, 32.5 30.1, 25.0 31.4 27.5 -3.9

    What the patches do:

    • Targets configured drop by about 40%: linux goes from 83,980 to 50,716 and windows from 91,991 to 55,703. Packages loaded stay the same (426 and 398).
    • In the windows profiles, package creation for @rules_py+//uv/private/constraints/platform (0.79s) and @go_toolchains// (0.37s) is gone.

    Why windows is slower, from the p1 profiles (main vs branch):

    • The whole branch timeline is slower, including module resolution before any patch could matter: compute main repo mapping takes 5.1s vs 2.2s.
    • Both fetch the same repos and evaluate the same module extensions, yet repo fetching totals 224.5s vs 166.7s.
    • Neither profile shows a cache miss or an extra extension evaluation that would explain it. But both branch pairs were slower by the same amount, so I can't call it runner noise.

    linux clears the 2s bar, but windows_x86_64 is more than 2s slower on both measures, so the change does not meet the rule. #9203 stays blocked until rules_go#4779 and rules_py#1675 land upstream. The patches are still on branch issue-9203-toolchain-patches if someone wants to measure again.

    🤖 Generated with Claude Code

    https://claude.ai/code/session_01Xut2hzpb4qWNZKpDCrwUz7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Improve and finish existing featuresblockedWaiting on upstream or a design decision

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions