Nightly cargo is sometimes slow to start #57774
Assignees
Comments
|
It seems like anything in nightly playground times out. CC @rust-lang/infra |
estebank
added
I-crash
moxian
changed the title
|
The version in the playground is The basic functionality with no crates works in a timely fashion: Building with all the crates is much slower: Considering we pre-compile all the dependencies and the only difference should be the content of However, updating
|
|
@ehuss I note that the Cargo timestamp functionality stuff landed — does that seem like it might be involved in this? |
|
@shepmaster can you show me how to reproduce that 10s time? Is there a Cargo.toml I can use? |
It's "easy" once you have Docker running: You might not see 10 seconds as that probably depends on the playground machine specifics, but you can see a district difference between the first build (slow) and a second build with a completely new main.rs (faster)
Basically the same idea in the corresponding Cargo issue. TL;DR: This wouldn't be the first time that Cargo and Docker have argued about filesystem times. |
|
|
Here's a 3.7 MB log of |
|
Yea, it definitely seems like it is related to the mtime updates. I suspect Docker is doing a copy-on-write, and it is just slow in some cases (my machine with a fast ssd can do it in about 2s, but my slower one takes over 11s). @Eh2406 @alexcrichton do you have any ideas on how to address this? I'm thinking maybe the mtime updates should be put behind a nightly-experimental flag until a solution is reached. One possible solution is to keep track of last-use data in a single file instead of using filesystem mtimes. It would probably need to be well optimized to be able to track thousands of crates, and to be able to quickly query and update it. |
This would be pretty typical for Docker, so that seems believable.
I'm seeing similar times on my SSD. Presumably AWS EC2 has a spinning rust drive. |
Mark-Simulacrum
changed the title
Mark-Simulacrum
changed the title
bors
added a commit
to rust-lang/cargo
that referenced
this issue
Jan 20, 2019
Put mtime-on-use behind a feature flag. This places #6477 behind the `-Z mtime-on-use` feature flag. The change to update the mtime each time a crate is used has caused a performance regression on the rust playground (rust-lang/rust#57774). It is using about 241 pre-built crates in a Docker container. Due to the copy-on-write nature of Docker, it can take a significant amount of time to update the timestamps (over 10 seconds on slower systems). cc @Mark-Simulacrum
Would it help to only touch one small file instead all the big output files? It would remove the
That would work, or we can just back them out until we have a better plan. I see you already have a PR, thanks!
That is a possibility, but more complicated than it may seem.
|
Merged
bors
added a commit
that referenced
this issue
Jan 21, 2019
Update cargo Pull in fix for #57774. 6 commits in ffe65875fd05018599ad07e7389e99050c7915be..907c0febe7045fa02dff2a35c5e36d3bd59ea50d 2019-01-17 23:57:50 +0000 to 2019-01-20 22:31:07 +0000 - Put mtime-on-use behind a feature flag. (rust-lang/cargo#6573) - Fix a typo in the unstable docs (rust-lang/cargo#6569) - Perhaps you meant: foo, bar or foobar (rust-lang/cargo#6550) - Refactor: Create uninstall submodule (rust-lang/cargo#6557) - Fix spurious Windows errors with switch_features_rerun. (rust-lang/cargo#6561) - Stop building on master on Travis. (rust-lang/cargo#6562) r? @Mark-Simulacrum
|
This is now fixed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
fails to compile on nightly (in playground), timing out : https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=ddbfcdb9f8be5d6984f1886cc201489e
Compiles fine on stable and nightly
The text was updated successfully, but these errors were encountered: