-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std: Improve downstream codegen in Command::env
#64186
Conversation
This commit rejiggers the generics used in the implementation of `Command::env` with the purpose of reducing the amount of codegen that needs to happen in consumer crates, instead preferring to generate code into libstd. This was found when profiling the compile times of the `cc` crate where the binary rlib produced had a lot of `BTreeMap` code compiled into it but the crate doesn't actually use `BTreeMap`. It turns out that `Command::env` is generic enough to codegen the entire implementation in calling crates, but in this case there's no performance concern so it's fine to compile the code into the standard library. This change is done by removing the generic on the `CommandEnv` map which is intended to handle case-insensitive variables on Windows. Instead now a generic isn't used but rather a `use` statement defined per-platform is used. With this commit a debug build of `Command::new("foo").env("a", "b")` drops from 21k lines of LLVM IR to 10k.
(rust_highfive has picked a reviewer for you, use r? to override) |
r? @sfackler |
Could this also be handled by a shim method at the |
Yeah this could be handled either way, and that's how it works today where the generic |
Yeah, it is a bit weird to use a generic with exactly one instantiation. @bors r+ |
📌 Commit 0b7ba6e has been approved by |
…=sfackler std: Improve downstream codegen in `Command::env` This commit rejiggers the generics used in the implementation of `Command::env` with the purpose of reducing the amount of codegen that needs to happen in consumer crates, instead preferring to generate code into libstd. This was found when profiling the compile times of the `cc` crate where the binary rlib produced had a lot of `BTreeMap` code compiled into it but the crate doesn't actually use `BTreeMap`. It turns out that `Command::env` is generic enough to codegen the entire implementation in calling crates, but in this case there's no performance concern so it's fine to compile the code into the standard library. This change is done by removing the generic on the `CommandEnv` map which is intended to handle case-insensitive variables on Windows. Instead now a generic isn't used but rather a `use` statement defined per-platform is used. With this commit a debug build of `Command::new("foo").env("a", "b")` drops from 21k lines of LLVM IR to 10k.
…=sfackler std: Improve downstream codegen in `Command::env` This commit rejiggers the generics used in the implementation of `Command::env` with the purpose of reducing the amount of codegen that needs to happen in consumer crates, instead preferring to generate code into libstd. This was found when profiling the compile times of the `cc` crate where the binary rlib produced had a lot of `BTreeMap` code compiled into it but the crate doesn't actually use `BTreeMap`. It turns out that `Command::env` is generic enough to codegen the entire implementation in calling crates, but in this case there's no performance concern so it's fine to compile the code into the standard library. This change is done by removing the generic on the `CommandEnv` map which is intended to handle case-insensitive variables on Windows. Instead now a generic isn't used but rather a `use` statement defined per-platform is used. With this commit a debug build of `Command::new("foo").env("a", "b")` drops from 21k lines of LLVM IR to 10k.
Rollup of 10 pull requests Successful merges: - #63676 (Use wasi crate for Core API) - #64094 (Improve searching in rustdoc and add tests) - #64111 (or-patterns: Uniformly use `PatKind::Or` in AST & Fix/Cleanup resolve) - #64156 (Assume non-git LLVM is fresh if the stamp file exists) - #64161 (Point at variant on pattern field count mismatch) - #64174 (Add missing code examples on Iterator trait) - #64175 (Fix invalid span generation when it should be div) - #64186 (std: Improve downstream codegen in `Command::env`) - #64190 (fill metadata in rustc_lexer's Cargo.toml) - #64198 (Add Fuchsia to actually_monotonic) Failed merges: r? @ghost
☔ The latest upstream changes (presumably #64209) made this pull request unmergeable. Please resolve the merge conflicts. |
This commit rejiggers the generics used in the implementation of
Command::env
with the purpose of reducing the amount of codegen thatneeds to happen in consumer crates, instead preferring to generate code
into libstd.
This was found when profiling the compile times of the
cc
crate wherethe binary rlib produced had a lot of
BTreeMap
code compiled into itbut the crate doesn't actually use
BTreeMap
. It turns out thatCommand::env
is generic enough to codegen the entire implementation incalling crates, but in this case there's no performance concern so it's
fine to compile the code into the standard library.
This change is done by removing the generic on the
CommandEnv
mapwhich is intended to handle case-insensitive variables on Windows.
Instead now a generic isn't used but rather a
use
statement definedper-platform is used.
With this commit a debug build of
Command::new("foo").env("a", "b")
drops from 21k lines of LLVM IR to 10k.