Skip to content
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

Merged
merged 1 commit into from
Sep 6, 2019

Conversation

alexcrichton
Copy link
Member

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.

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
Copy link
Collaborator

r? @withoutboats

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 5, 2019
@alexcrichton
Copy link
Member Author

r? @sfackler

@sfackler
Copy link
Member

sfackler commented Sep 5, 2019

Could this also be handled by a shim method at the Command level to call a non-generic Command::env_inner?

@alexcrichton
Copy link
Member Author

Yeah this could be handled either way, and that's how it works today where the generic Command methods call concrete (most of the time) methods in sys. This one just happened to still be generic and require monomorphization though. I'd be fine with either strategy but the extra generic felt a bit weird to me in general here

@sfackler
Copy link
Member

sfackler commented Sep 5, 2019

Yeah, it is a bit weird to use a generic with exactly one instantiation.

@bors r+

@bors
Copy link
Contributor

bors commented Sep 5, 2019

📌 Commit 0b7ba6e has been approved by sfackler

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 5, 2019
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Sep 6, 2019
…=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.
Centril added a commit to Centril/rust that referenced this pull request Sep 6, 2019
…=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.
bors added a commit that referenced this pull request Sep 6, 2019
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
@bors bors merged commit 0b7ba6e into rust-lang:master Sep 6, 2019
@bors
Copy link
Contributor

bors commented Sep 6, 2019

☔ The latest upstream changes (presumably #64209) made this pull request unmergeable. Please resolve the merge conflicts.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Sep 6, 2019
@alexcrichton alexcrichton deleted the improve-env-codegen branch September 20, 2019 18:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants