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

Cargo spends most of 'cargo build' time writing to output on Windows #6661

Closed
LPGhatguy opened this issue Feb 13, 2019 · 2 comments
Closed
Labels
C-bug Category: bug

Comments

@LPGhatguy
Copy link

LPGhatguy commented Feb 13, 2019

Problem
I have a Rust project with around 250 total dependencies. It's pretty cool, you can see it here: https://github.com/LPGhatguy/rojo

When I run cargo build with no code changes after a complete build, Cargo takes around 2600ms. When I redirect stderr to /dev/null or pass the -q flag, that time drops to around 490ms.

Time with output showing in console:

$ time cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 2.46s

real    0m2.559s
user    0m0.000s
sys     0m0.015s

$ time cargo build
    Finished dev [unoptimized + debuginfo] target(s) in 2.51s

real    0m2.603s
user    0m0.015s
sys     0m0.000s

Time redirecting stderr to /dev/null:

$ time cargo build 2>/dev/null

real    0m0.493s
user    0m0.000s
sys     0m0.015s

$ time cargo build 2>/dev/null

real    0m0.490s
user    0m0.000s
sys     0m0.030s

Steps

  1. Be on Windows
  2. Compile a Rust project via cargo build via cmd.exe
  3. Weep

Possible Solution(s)

cargo build -p and cargo build 2>/dev/null both suppress the progress bar output and fix the problem, but I like the progress bar because it's pretty and helpful.

Windows' terminal emulator, ConHost, has very very slow writes. I have lots of crates!

Notes
Windows 10, build 1809, using Git Bash or cmd.exe, which both use ConHost.

Output of cargo version:

$ cargo version
cargo 1.32.0 (8610973aa 2019-01-02)
@LPGhatguy LPGhatguy added the C-bug Category: bug label Feb 13, 2019
@ehuss
Copy link
Contributor

ehuss commented Feb 13, 2019

Thanks for the report. I think this may be fixed (or at least better) on the latest nightly. Can you try with nightly and see how it goes? I think it needs to be a a nightly after 2019-02-06.

@LPGhatguy
Copy link
Author

@ehuss Looks great on nightly! Thanks for the tip!

$ time cargo +nightly build
    Finished dev [unoptimized + debuginfo] target(s) in 0.38s

real    0m0.481s
user    0m0.000s
sys     0m0.015s
$ time cargo +nightly build 2>/dev/null

real    0m0.468s
user    0m0.000s
sys     0m0.015s

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

No branches or pull requests

2 participants