-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Very long iterative compile times for cargo doc
on workspaces with many crates
#82845
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
Comments
@alice-i-cecile What version of rustdoc are you using? What is the output of |
How do I check the version of my rustdoc? |
Without changes:
With single file change:
|
@jyn514 I've run the second command, but can't upload it here (even as a .zip) due to it being over 10 MB. Suggestions? |
Can you upload it to google drive or something? Or some other file hosting site?
Hmm, this seems to be missing almost two-thirds of the time (to be clear, this is a bug in |
|
Ok, I didn't realize initially that by "project" you meant a workspace. Here's the times for a trivial change to
This will be a lot harder to fix - no individual crate takes too long ( |
FWIW a potentially faster fix in the meantime could be to pass -p for the specific crate you're editing the docs for, and just view those, which would avoid waiting for reverse dependencies to rebuild. |
cargo doc
on large projectcargo doc
on workspaces with many crates
And I think another way to do that is to |
Avoid temporary allocations in `render_assoc_item` `render_assoc_item` came up as very hot in a profile of rustdoc on `bevy`. This avoids some temporary allocations just to calculate the length of the header. This should be a strict improvement, since all string formatting was done twice before. cc rust-lang#82845
I'm attempting to update the docs of Bevy, a relatively large Rust crate.
Building the docs using
cargo doc
initially takes about 90s. Rebuilding the docs usingcargo doc
without making any changes takes less than a second. Making any change to the doc strings within even a single file (e.g.Entity
) seems to cause each subcrate to be redocumented, taking another 90s.This obviously makes it quite challenging to check how my changes are displayed.
The text was updated successfully, but these errors were encountered: