Conversation
The slow codex-core rebuilds are dominated by debug-info codegen, not parsing or type checking. On a warm-dependency package rebuild, the baseline codex-core compile was about 39.5s wall / 38.9s rustc total, with codegen_crate around 14.0s and LLVM_passes around 13.4s. Setting codex-core to line-tables-only debug info brought that to about 27.2s wall / 26.7s rustc total, with codegen_crate around 3.1s and LLVM_passes around 2.8s. I also sampled other first-party crates instead of keeping a codex-core-only package override. codex-app-server showed the same pattern: rustc total dropped from 15.85s to 10.48s, while codegen_crate plus LLVM_passes dropped from about 13.47s to 3.23s. codex-app-server-protocol had a smaller but still real improvement, 16.05s to 14.58s total, and smaller crates showed modest wins. That points to a workspace dev-profile policy rather than a hand-maintained list of large crates. Use `[profile.dev] debug = 1` so local dev builds keep line tables and useful backtraces while avoiding full variable debug info. This can cause a one-time rebuild because the Cargo dev profile hash changes, but subsequent rebuilds avoid the expensive debug-info work. Bazel does not read Cargo profiles for this setting. rules_rust derives debuginfo from Bazel toolchain/compilation-mode settings and the current fastbuild action already emitted `--codegen=debuginfo=0`. This change makes the CI choice explicit for both target and exec-configuration Rust actions with `-Cdebuginfo=0`. Verification: - `just bazel-lock-update` - `just bazel-lock-check` - `cargo check -p codex-core --lib` - `cargo test -p codex-core --lib` - Bazel `aquery --config=ci-linux` confirmed `--codegen=debuginfo=0` and `-Cdebuginfo=0` for `//codex-rs/core:core`
pakrym-oai
approved these changes
Apr 21, 2026
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
What changed
This PR makes the default Cargo dev profile use line-tables-only debug info:
That keeps useful backtraces while avoiding the cost of full variable debug
info in normal local dev builds.
This also makes the Bazel CI setting explicit with
-Cdebuginfo=0for targetand exec-configuration Rust actions. Bazel/rules_rust does not read Cargo
profiles for this setting, and the current fastbuild action already emitted
--codegen=debuginfo=0; the Bazel part of this PR makes that choice direct inour build configuration.
Why
The slow codex-core rebuilds are dominated by debug-info codegen, not parsing
or type checking. On a warm-dependency package rebuild, the baseline
codex-core compile was about 39.5s wall / 38.9s rustc total, with
codegen_crate around 14.0s and LLVM_passes around 13.4s. Setting codex-core
to line-tables-only debug info brought that to about 27.2s wall / 26.7s rustc
total, with codegen_crate around 3.1s and LLVM_passes around 2.8s.
debug = 0was only about another 0.7s faster thandebug = 1in thecodex-core measurement, so
debug = 1is the better default dev tradeoff: itcaptures nearly all of the compile-time win while preserving basic
debuggability.
I also sampled other first-party crates instead of keeping a codex-core-only
package override. codex-app-server showed the same pattern: rustc total
dropped from 15.85s to 10.48s, while codegen_crate plus LLVM_passes dropped
from about 13.47s to 3.23s. codex-app-server-protocol had a smaller but still
real improvement, 16.05s to 14.58s total, and smaller crates showed modest
wins. That points to a workspace dev-profile policy rather than a
hand-maintained list of large crates.
Relationship to #18612
#18612 added the
dev-smallprofile. That remains useful when someone wants a working local build quickly
and is willing to opt in with
cargo build --profile dev-small.This PR is deliberately less aggressive: it changes the common default dev
profile while preserving line tables/backtraces.
dev-smallremains theexplicit "build quickly, no debuggability concern" path.
Other investigation
I looked for another structural win comparable to
#16631 and
#16630, but did not find one.
The attempted TOML monomorphization changes were noisy or worse in
measurement, and the async task changes reduced some instantiations but only
translated to roughly a one-second improvement while being much more
disruptive. The debug-info setting was the one repeatable, material win that
survived measurement.
Verification
just bazel-lock-updatejust bazel-lock-checkcargo check -p codex-core --libcargo test -p codex-core --libaquery --config=ci-linuxconfirmed--codegen=debuginfo=0and-Cdebuginfo=0for//codex-rs/core:coreStack created with Sapling. Best reviewed with ReviewStack.