-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Add a progress indicator for cargo clean
#10236
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon. Please see the contribution instructions for more information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The progress bar seems disappear when --verbose
is specified with -p
. I guess it is replaced by the output of Removing ...
. We can tick the progress bar after each rm_rf
, but if a removal is stuck the progress bar still disappears for a while.
src/cargo/ops/cargo_clean.rs
Outdated
let pkg_dir = format!("{}-*", pkg.name()); | ||
progress.tick_now(pkg_idx + 1, packages.len(), &format!(": {}", pkg.name()))?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if there is a package with lots of artifacts? I feel like it would still look like "get stuck"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would. I added a message listing of the # of files/folders cleaned so users can see that it isn't stuck.
src/cargo/ops/cargo_clean.rs
Outdated
if entry.file_type().is_dir() { | ||
paths::remove_dir(entry.path())?; | ||
} else { | ||
paths::remove_file(entry.path())?; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure but maybe keep the verbose Removing ...
as what fn rm_rf
does? Though it only displays Removing /path/to/target-dir
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, updated so the verbose Removing ...
is kept.
src/cargo/ops/cargo_clean.rs
Outdated
@@ -231,6 +235,25 @@ fn rm_rf_glob(pattern: &Path, config: &Config) -> CargoResult<()> { | |||
Ok(()) | |||
} | |||
|
|||
fn rm_rf_with_progress(path: &Path, progress: &mut Progress<'_>) -> CargoResult<()> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NIT: Feel like progress
can be a part of function body instead of a parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome. I think it's good to move forward and wait the review from maintainers. 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable to me, thanks for this!
Ok(()) | ||
} | ||
|
||
fn clean_entire_folder(path: &Path, config: &Config) -> CargoResult<()> { | ||
let num_paths = walkdir::WalkDir::new(path).into_iter().count(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This naively seems like it would have a large impact and slow things down because we have to walk everything before actually removing everything. I don't have a great sense for the practical impact of this though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative to this I think would be to perform the walk once, collect a list of all paths to remove, then remove them all in a loop. That would mean we only have to walk once and should be similar in performance I think.
src/cargo/ops/cargo_clean.rs
Outdated
fn rm_rf_glob( | ||
pattern: &Path, | ||
config: &Config, | ||
progress: &mut impl CleaningProgressBar, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd be ok to change this from impl Cleaning...
to dyn Cleaning...
since we don't need the monomorphization aspect here per se
Just to echo some of Alex's comments, can you do some benchmarking and report if there is a performance hit with this? I think it would be good to test with some medium-ish sized projects, and on different systems (windows in particular has some slow fs behaviors). A small hit is fine, but if this makes |
I'll do some benchmarking :) didn't realize that Windows had some peculiarities |
Co-authored-by: Weihang Lo <weihanglo@users.noreply.github.com>
Co-authored-by: Weihang Lo <weihanglo@users.noreply.github.com>
Running Before these changes: After these changes: So it looks like there is a performance regression of ~12% on Windows. Running Before these changes: After these changes: Performance doesn't have seemed to change much on my mac. I'll experiment with collecting the paths into a vector. |
I did some testing on various systems and different project sizes, and got roughly the same performance hit that you mentioned (ranging from 0 to 10%). The small performance hit is a bit unfortunate, but overall I don't think will be noticed much. I'm a little concerned for using cargo over a slow network connection, as I think this could tick quite frequently. I think there can possibly be followup in the future if that turns into a serious concern. Another possibility is to explore deleting files in parallel. @rust-lang/cargo I'm going to just do a quick fcp check since this changes the output of a stable command, and there is a small performance hit. @rfcbot fcp merge |
Team member @ehuss has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
📌 Commit 60cfe7e has been approved by |
☀️ Test successful - checks-actions |
Update cargo 11 commits in e2e2dddebe66dfc1403a312653557e332445308b..dba5baf4345858c591517b24801902a062c399f8 2022-04-05 17:04:53 +0000 to 2022-04-13 21:58:27 +0000 - Part 6 of RFC2906 - Switch the inheritance source from `workspace` to… (rust-lang/cargo#10564) - Part 5 of RFC2906 - Add support for inheriting `rust-version` (rust-lang/cargo#10563) - Add support for rustc --check-cfg well known names and values (rust-lang/cargo#10486) - Reserve filename `Cargo.toml.orig` in `cargo package` (rust-lang/cargo#10551) - Retry command invocation with argfile (rust-lang/cargo#10546) - Add a progress indicator for `cargo clean` (rust-lang/cargo#10236) - Ensure host units don't depend on Docscrape units, fixes rust-lang/cargo#10545 (rust-lang/cargo#10549) - Fix docs: Bindeps env vars are passed to build script at runtime (rust-lang/cargo#10550) - Part 4 of RFC2906 - Add support for inheriting `readme` (rust-lang/cargo#10548) - Part 3 of RFC2906 - Add support for inheriting `license-path`, and `depednency.path` (rust-lang/cargo#10538) - Bump to 0.63.0, update changelog (rust-lang/cargo#10544)
Update cargo 11 commits in e2e2dddebe66dfc1403a312653557e332445308b..dba5baf4345858c591517b24801902a062c399f8 2022-04-05 17:04:53 +0000 to 2022-04-13 21:58:27 +0000 - Part 6 of RFC2906 - Switch the inheritance source from `workspace` to… (rust-lang/cargo#10564) - Part 5 of RFC2906 - Add support for inheriting `rust-version` (rust-lang/cargo#10563) - Add support for rustc --check-cfg well known names and values (rust-lang/cargo#10486) - Reserve filename `Cargo.toml.orig` in `cargo package` (rust-lang/cargo#10551) - Retry command invocation with argfile (rust-lang/cargo#10546) - Add a progress indicator for `cargo clean` (rust-lang/cargo#10236) - Ensure host units don't depend on Docscrape units, fixes rust-lang/cargo#10545 (rust-lang/cargo#10549) - Fix docs: Bindeps env vars are passed to build script at runtime (rust-lang/cargo#10550) - Part 4 of RFC2906 - Add support for inheriting `readme` (rust-lang/cargo#10548) - Part 3 of RFC2906 - Add support for inheriting `license-path`, and `depednency.path` (rust-lang/cargo#10538) - Bump to 0.63.0, update changelog (rust-lang/cargo#10544)
Closes #9981.
Cleaning the entire
target
directory:Cleaning some packages: