perf: cache resolved zig command in wrapper scripts to skip per-invocation probes - #469
Merged
Conversation
…ation probes find_zig() ran on every compiler invocation and always spawned `python -m ziglang version` (paying Python interpreter startup just to fail on systems without the pip package) and then `zig version` for validation — ~40ms per zig cc call even though the toolchain was already resolved and validated when the wrapper was generated. Export the resolved command as CARGO_ZIGBUILD_ZIG_COMMAND(_ARGS) in the generated wrapper scripts and trust it in find_zig() when the path still exists, falling back to probing otherwise. Measured on macOS (zig 0.16.0): wrapper overhead vs raw zig cc drops from ~52ms to ~11ms per invocation (85ms -> 44ms total for a -### call). Fixes #244 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W1Kk6AucizDRZdBDVGipXF
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Addresses the per-invocation overhead measured in #244.
find_zig()runs on everycargo-zigbuild zig ccinvocation and always spawned two processes before doing any work:python -m ziglang version— paying full Python interpreter startup (~15ms) just to fail on systems without the pip package,zig version— ~31ms of zig startup for validation, even thoughCARGO_ZIGBUILD_ZIG_VERSIONalready carries the version.The toolchain was already resolved and validated when the wrapper script was generated, so re-probing per compile is pure waste — for C-heavy builds it's paid hundreds of times.
This exports the resolved command as
CARGO_ZIGBUILD_ZIG_COMMAND(+CARGO_ZIGBUILD_ZIG_COMMAND_ARGSfor thepython -m ziglangmode) in the generated sh and bat wrappers, and hasfind_zig()trust it when the path still exists — falling back to the normal probe order if it doesn't (e.g. zig was moved between builds; the next wrapper regeneration re-resolves).Numbers (macOS, zig 0.16.0, hyperfine, real-build env)
-###callzig cc -###The remaining ~11ms is sh + cargo-zigbuild binary startup and arg filtering.
Verified:
cargo test --libpasses; real builds foraarch64-apple-darwinandx86_64-unknown-linux-gnu.2.17regenerate wrappers with the new exports and build cleanly. Clippy warnings are pre-existing.🤖 Generated with Claude Code
https://claude.ai/code/session_01W1Kk6AucizDRZdBDVGipXF