## Summary

This PR enables PGO for Ruff releases, starting with Linux x86-64.

### Design

The release pipeline is modified as follows:

- We build an instrumented, stripped release binary.
- We run `check` and `format` on a corpus of projects from our ecosystem
reports -- specifically, eight of the pinned ecosystem projects that we
use in the ty CI. (In total, it's 502 Python and stub files.)
- We merge the profiles via `llvm-profdata`.
- We feed the result back into the existing `maturin` build.

### Results

We evaluate performance on a held-out corpus: Prefect, Django, Pandas,
scikit-learn, SciPy, and SymPy.

Results are as follows:

| Held-out project | `ruff check` | `ruff format` |
| --- | ---: | ---: |
| Django | 10.9% faster | 6.6% faster |
| pandas | 16.3% faster | 9.7% faster |
| scikit-learn | 10.8% faster | 7.9% faster |
| SciPy | 14.7% faster | 5.6% faster |
| SymPy | 17.1% faster | 11.4% faster |
| Geometric mean | **14.0% faster** | **8.3% faster** |

Beyond runtime:

- **Binary size decreased by 6.2%** (27.96 MB to 26.23 MB).
- **Release pipeline gets about 2x longer** (non-PGO release build took
7m22s; PGO pipeline took 15m14s (8m35s instrumented training plus 6m39s
optimized wheel).

### Stack

Additional platforms are covered in subsequent PRs in the stacked;
platforms that are lower-priority at at-all difficult to run on natively
are omitted. In the end, I'm targeting Linux x86-64, Linux ARM, macOS
ARM, and Windows x86-64.

I also attempted BOLT in #27588,
but I've decided against pursuing that for now; see the results in that
PR which speak for themselves.

ty and uv will follow the same approach; see the stacks here:

- astral-sh/ty#4213
- astral-sh/uv#21001

See: #7055.

## Summary

This PR enables PGO for ty's macOS ARM64 releases, following the
approach outlined in #4213. The
existing linker configuration and safe identical-code folding are
preserved.

Across seven held-out macOS projects, `ty check` finishes 5.0% faster
and uses 7.1% less CPU; incremental language-server edits are 7.3%
faster. The production executable is 3.6% smaller than without PGO,
although the wheel and release archive are each 2.8% larger.

The macOS ARM64 release job uses the same Namespace runner as Ruff,
reducing its full-stack PGO build from 23m 47s to 6m 39s (72%). Three
Namespace builds finished in 6m 38s to 7m 59s; the previous Depot runner
took 11m 20s.

## Summary

This PR enables PGO for ty's Windows x86-64 releases, following the
approach outlined in #4213. Both
builds preserve static Visual C++ runtime linking.

On the Windows holdout set, `ty check` uses 19.7% less CPU and finishes
17.5% faster, while incremental language-server edits get 14.7% faster.
The release binary gets 9.6% smaller, and the wheel and release archive
each get 3.4% smaller.

Only the Windows x86-64 PGO job uses the same 16-core Namespace runner
as Ruff, reducing the full-stack build from 26m 08s to 12m 24s (53%).
The previous 32-core Depot runner took 14m 17s. With Linux x86-64 at 11m
28s and Linux ARM64 at 11m 37s, Windows is now the release bottleneck.
The remaining Windows targets keep their existing runners.

## Summary

This PR enables PGO for ty's Linux ARM64 releases, following the
approach outlined in #4213. (To
enable PGO, we also move to a native ARM64 runner.) The existing
jemalloc page-size configuration is preserved.

Across four held-out Linux ARM64 projects, `ty check` uses 15.0% less
CPU and finishes 11.9% faster. The release binary gets 4.9% smaller, the
wheel gets 1.2% smaller, and the release archive gets 1.4% smaller.

The Linux ARM64 PGO build uses an eight-core Depot runner, reducing its
runtime from 14m 51s on a four-core GitHub runner to 11m 37s (22%). In
the matched full-stack run, eight-core Linux x86-64 finished in 11m 28s
and Namespace Windows finished in 12m 24s, making Windows the release
bottleneck.

## Summary

This PR enables PGO for Ruff releases, starting with Linux x86-64.

### Design

The release pipeline is modified as follows:

- We build an instrumented, stripped release binary.
- We run `check` and `format` on a corpus of projects from our ecosystem
reports -- specifically, eight of the pinned ecosystem projects that we
use in the ty CI. (In total, it's 502 Python and stub files.)
- We merge the profiles via `llvm-profdata`.
- We feed the result back into the existing `maturin` build.

### Results

We evaluate performance on a held-out corpus: Prefect, Django, Pandas,
scikit-learn, SciPy, and SymPy.

Results are as follows:

| Held-out project | `ruff check` | `ruff format` |
| --- | ---: | ---: |
| Django | 10.9% faster | 6.6% faster |
| pandas | 16.3% faster | 9.7% faster |
| scikit-learn | 10.8% faster | 7.9% faster |
| SciPy | 14.7% faster | 5.6% faster |
| SymPy | 17.1% faster | 11.4% faster |
| Geometric mean | **14.0% faster** | **8.3% faster** |

Beyond runtime:

- **Binary size decreased by 6.2%** (27.96 MB to 26.23 MB).
- **Release pipeline gets about 2x longer** (non-PGO release build took
7m22s; PGO pipeline took 15m14s (8m35s instrumented training plus 6m39s
optimized wheel).

### Stack

Additional platforms are covered in subsequent PRs in the stacked;
platforms that are lower-priority at at-all difficult to run on natively
are omitted. In the end, I'm targeting Linux x86-64, Linux ARM, macOS
ARM, and Windows x86-64.

I also attempted BOLT in astral-sh#27588,
but I've decided against pursuing that for now; see the results in that
PR which speak for themselves.

ty and uv will follow the same approach; see the stacks here:

- astral-sh/ty#4213
- astral-sh/uv#21001

See: astral-sh#7055.

## Summary

This PR enables PGO for uv releases, starting with Linux x86-64.

### Design

The release pipeline is modified as follows:

- We build instrumented `uv` and `uvx` release binaries inside the
existing manylinux container.
- We train directly on eleven shared `test/ecosystem` fixtures:
cibuildwheel, Cookiecutter, Flask, HTTPX, LLM, the OpenAI Python SDK,
Poetry, pytest-cov, Sentry, Zulip, and the 38-project pyx workspace.
- Every project exercises cold and warm `uv pip compile` resolution,
cold and warm `uv lock` resolution, `uv export`, `uv pip` installation,
and `uv sync` installation on every release platform.
- Per-project `exclude-dependencies` settings omit packages without
compatible release-platform wheels while preserving the rest of each
real dependency graph.
- Raw profiles are merged online by workload family, then merged with
`llvm-profdata` and fed back into the existing `maturin` build.
- JupyterLab, Saleor, Semantic Kernel, Transformers, and Warehouse
remain separate, held-out evaluation projects.

### Results

We benchmarked the builds on Linux x86-64 using the expanded corpus for
training and five separate held-out ecosystem projects for evaluation.

| Held-out project | Dependency resolution | Wheel installation |
Project locking | Lockfile export |
| ---------------- | --------------------: | -----------------: |
---------------: | --------------: |
| JupyterLab | 11.2% faster | 0.0% | 10.1% faster | 10.6% faster |
| Semantic Kernel | 9.3% faster | 7.1% faster | 12.5% faster | 8.7%
faster |
| Transformers | 11.7% faster | 4.1% faster | 9.5% faster | 11.0% faster
|
| Saleor | — | — | 9.7% faster | 10.0% faster |
| Warehouse | — | — | 9.7% faster | 7.6% faster |
| Geometric mean | **10.7% faster** | **3.7% faster** | **10.3% faster**
| **9.6% faster** |

Across all sixteen held-out workloads, wall time decreased by **8.9%**
(95% CI: 8.4–9.8%) and CPU time decreased by **8.4%** (95% CI:
7.9–9.0%). The matched Linux executable was **13.3% smaller** (58.91 MB
to 51.05 MB), or **12.3% smaller** after gzip compression (22.68 MB to
19.90 MB).

(Saleor and Warehouse include source-only dependencies, so they are
benchmarked on locking and export rather than wheel-only installation.)

### Stack

Additional platforms are covered in subsequent PRs in the stack: macOS
ARM64, Windows x86-64, and Linux ARM64.

Ruff and ty follow the same approach; see the stacks here:

- astral-sh/ruff#27570
- astral-sh/ty#4213

This PR enables PGO for uv releases, starting with Linux x86-64.

The release pipeline is modified as follows:

- We build instrumented `uv` and `uvx` release binaries inside the
existing manylinux container.
- We train directly on eleven shared `test/ecosystem` fixtures:
cibuildwheel, Cookiecutter, Flask, HTTPX, LLM, the OpenAI Python SDK,
Poetry, pytest-cov, Sentry, Zulip, and the 38-project pyx workspace.
- Every project exercises cold and warm `uv pip compile` resolution,
cold and warm `uv lock` resolution, `uv export`, `uv pip` installation,
and `uv sync` installation on every release platform.
- Per-project `exclude-dependencies` settings omit packages without
compatible release-platform wheels while preserving the rest of each
real dependency graph.
- Raw profiles are merged online by workload family, then merged with
`llvm-profdata` and fed back into the existing `maturin` build.
- JupyterLab, Saleor, Semantic Kernel, Transformers, and Warehouse
remain separate, held-out evaluation projects.

We benchmarked the builds on Linux x86-64 using the expanded corpus for
training and five separate held-out ecosystem projects for evaluation.

| Held-out project | Dependency resolution | Wheel installation |
Project locking | Lockfile export |
| ---------------- | --------------------: | -----------------: |
---------------: | --------------: |
| JupyterLab | 11.2% faster | 0.0% | 10.1% faster | 10.6% faster |
| Semantic Kernel | 9.3% faster | 7.1% faster | 12.5% faster | 8.7%
faster |
| Transformers | 11.7% faster | 4.1% faster | 9.5% faster | 11.0% faster
|
| Saleor | — | — | 9.7% faster | 10.0% faster |
| Warehouse | — | — | 9.7% faster | 7.6% faster |
| Geometric mean | **10.7% faster** | **3.7% faster** | **10.3% faster**
| **9.6% faster** |

Across all sixteen held-out workloads, wall time decreased by **8.9%**
(95% CI: 8.4–9.8%) and CPU time decreased by **8.4%** (95% CI:
7.9–9.0%). The matched Linux executable was **13.3% smaller** (58.91 MB
to 51.05 MB), or **12.3% smaller** after gzip compression (22.68 MB to
19.90 MB).

(Saleor and Warehouse include source-only dependencies, so they are
benchmarked on locking and export rather than wheel-only installation.)

Additional platforms are covered in subsequent PRs in the stack: macOS
ARM64, Windows x86-64, and Linux ARM64.

Ruff and ty follow the same approach; see the stacks here:

- astral-sh/ruff#27570
- astral-sh/ty#4213