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

gc: Verify performance numbers #13058

Open
ehuss opened this issue Nov 28, 2023 · 0 comments
Open

gc: Verify performance numbers #13058

ehuss opened this issue Nov 28, 2023 · 0 comments
Assignees
Labels
A-caching Area: caching of dependencies, repositories, and build artifacts S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review Z-gc Nightly: garbage collection

Comments

@ehuss
Copy link
Contributor

ehuss commented Nov 28, 2023

For the gc support implemented in #12634, I did a lot of performance testing, but I haven't recorded any final numbers to verify that the performance hit is acceptable. I'd like to collect data on a variety of systems under typical and extreme conditions to understand the impact for various commands. Things I'd like to record are:

  • Automatic GC cleaning time hit relative to a "fresh" build (that is, a build of projects of various sizes where there are no rustc calls).
  • Cache usage recording time hit relative to a "fresh" build.
  • Time spent in cargo clean gc when synchronizing out-of-sync files (essentially, sync_db_with_files). For example, starting with a relatively large cache generated by older versions of cargo. This should be very fast (essentially scanning a few thousand files), but need to verify.
  • Time spent in cargo clean gc with a size option like --max-download-size when synchronizing out-of-sync files (sync_db_with_files with sync_size). This has to du over a potentially large number of files.

There are some benchmarks, but they are isolated and low-level. The examples above are targeted more towards the overall effect when integrated with the build code paths, or the cleaning code paths. We may want to consider extending the benchmarks if there are points that seem at risk.

@ehuss ehuss added A-caching Area: caching of dependencies, repositories, and build artifacts S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review Z-gc Nightly: garbage collection labels Nov 28, 2023
@ehuss ehuss self-assigned this Nov 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-caching Area: caching of dependencies, repositories, and build artifacts S-accepted Status: Issue or feature is accepted, and has a team member available to help mentor or review Z-gc Nightly: garbage collection
Projects
None yet
Development

No branches or pull requests

1 participant