## Summary

This PR enables BOLT for x86-64 releases. The net effect is: 4.23% less
wall-time, at the cost of a 9.9% larger wheel (and another 53 seconds in
the release pipeline).

| Project | ty 0.0.92 | This PR | Wall-time reduction (95% interval) |
Peak RSS, 0.0.92 → PR |
| --- | ---: | ---: | ---: | ---: |
| discord.py | 773 ms | 727 ms | 5.9% (3.5–8.3%) | 199.3 → 198.8 MiB |
| Jinja | 186 ms | 175 ms | 6.0% (4.0–7.9%) | 83.8 → 82.3 MiB |
| Black | 271 ms | 259 ms | 4.3% (0.8–7.3%) | 110.9 → 109.8 MiB |
| isort | 336 ms | 309 ms | 8.1% (4.8–11.2%) | 74.9 → 74.0 MiB |
| pandas-stubs | 280 ms | 258 ms | 7.8% (3.9–12.7%) | 142.7 → 140.1 MiB
|
| Prefect | 460 ms | 428 ms | 6.9% (3.0–10.9%) | 194.7 → 194.1 MiB |
| pandas | 2.55 s | 2.35 s | 7.7% (5.6–9.7%) | 539.7 → 539.0 MiB |
| PyTorch | 8.71 s | 8.24 s | 5.4% (1.9–9.8%) | 1,568.4 → 1,563.3 MiB |
| Home Assistant | 15.69 s | 15.25 s | 2.8% (−3.2% to 8.1%) | 3,422.4 →
3,423.6 MiB |

Co-authored-by: astral-automations-bot[bot] <305554984+astral-automations-bot[bot]@users.noreply.github.com>
Co-authored-by: Charlie Marsh <[email protected]>

## Summary

On older x86-64 Linux kernels, ty 0.0.93 aborts in `ld.so` before it
reaches `main`. Preserving the ELF layout that those kernels expect adds
2.06 MiB to the installed executable, but only 4.33 KiB to the wheel.

BOLT moves the ELF program header table after `.bss`. The loader
reserves memory for `.bss` and fills it with zeros, so those bytes take
up no space in the file. BOLT leaves a gap before the table so its file
offset matches its address relative to the load base. In 0.0.93, the
final `llvm-strip` step closed that gap, moving the table from file
offset `0x1f8a000` to `0x1d7b000` while leaving its virtual address at
`0x1f8a000`. Older kernels add the file offset to the load base to
compute `AT_PHDR`, so they pass the loader the wrong address.

We now let BOLT strip the symbol table and package its output directly
in the wheel and standalone archive. The Linux x86-64 GNU build runs
BOLT once with function splitting enabled. It fails if the rewritten
code does not fit in the original `.text` section or if the program
headers are mapped at an address older kernels cannot find.

To isolate the cost, we compared the PR executable with a copy passed
through the old `llvm-strip` step. Of the 2,159,056 extra bytes on disk,
2,158,592 are zeros in the gap.

| Artifact | Change from preserving the layout | PR build vs. published
0.0.93 |
| --- | ---: | ---: |
| Installed executable | +2.06 MiB (+6.20%) | +2.03 MiB |
| Wheel | +4.33 KiB (+0.027%) | −6.63 KiB |
| Standalone `.tar.gz` | +6.03 KiB (+0.038%) | −5.83 KiB |

Closes #4848.

Co-authored-by: astral-automations-bot[bot] <305554984+astral-automations-bot[bot]@users.noreply.github.com>

Speed up the release process by moving the `i686-pc-windows-msvc` and
`aarch64-pc-windows-msvc` binary builds from `windows-latest` to
`namespace-profile-windows-2022-x86-64-16x32`, the larger runner already
used for the x86-64 build. Signing waits for every binary build, so
speeding up the last builds lets signing and the subsequent release jobs
start earlier.

Ruff [already uses this profile for all three Windows
targets](https://github.com/astral-sh/ruff/blob/86c978007e6f6bcd7d3c9e362e3445056a328648/.github/workflows/build-binaries.yml#L202-L213),
so this change brings ty's runner selection into line with Ruff's. In
[Ruff's October 22
release](https://github.com/astral-sh/ruff/actions/runs/39826786436),
all three Windows builds succeeded on that profile: x86-64 took 6m48s,
i686 took 5m56s, and ARM64 took 6m18s.

The last three successful ty release runs, from October 2026, show the
opportunity:

| Release run | i686 on `windows-latest` | ARM64 on `windows-latest` |
x86-64 on Namespace, including PGO | Potential reduction in the
binary-build stage |
| --- | ---: | ---: | ---: | ---: |
| [October 22](https://github.com/astral-sh/ty/actions/runs/39827424261)
| 13m33s | 10m53s | 8m32s | 4m07s |
| [October 20](https://github.com/astral-sh/ty/actions/runs/39435426805)
| 12m52s | 13m29s | 9m05s | 2m30s |
| [October 16](https://github.com/astral-sh/ty/actions/runs/38885658621)
| 13m12s | 13m13s | 6m34s | 4m38s |

The final column uses actual job completion times, rather than
subtracting durations of jobs that started at different times. It is the
gap between the last i686/ARM64 build and the last other binary build:
x86-64 Windows on October 22 and 20, and ARM64 Linux on October 16. It
assumes both migrated builds finish by the time that other build
finishes, with the other jobs' timings unchanged. These are therefore
conditional upper bounds for the build-stage saving, not measured
improvements from this change.

In a separate [Ruff build on October
22](https://github.com/astral-sh/ruff/actions/runs/39839774050),
[i686](https://github.com/astral-sh/ruff/actions/runs/39839774050/job/120037395069)
and
[ARM64](https://github.com/astral-sh/ruff/actions/runs/39839774050/job/120037395126)
both built successfully on the same profile and finished before its
x86-64 PGO build. That finishing order is the basis for expecting the
migrated builds to stop delaying signing, although it does not establish
ty's new build times.

The expectation is a saving of a few minutes per release, with **roughly
2–4 minutes** as a working estimate to validate. If the assumptions
above hold, the full 2m30s–4m38s saving could carry through to release
completion. Publishing waits for both signed release artifacts and
Docker; in each of these timelines, Docker would still finish before the
earlier signing and artifact-preparation jobs reached publishing.
Relative to the observed full workflow durations of about 25–29 minutes,
those conditional savings are about 9–19%. Runner queue times, approval
delays, and differences between target builds could reduce the benefit;
these runs are evidence of the bottleneck, not a controlled runner
benchmark.

The change only removes the x86-64 restriction from runner selection.
Forks retain `windows-latest`; target-specific Python architectures,
build settings, PGO scope, smoke tests, signing, native verification,
and disabled shared caches are preserved.

Co-authored-by: astral-automations-bot[bot] <305554984+astral-automations-bot[bot]@users.noreply.github.com>