-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
[rustdoc] Calculate span information on demand instead of storing it ahead of time #79957
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This brings stm32h7 to 2425472 KB used (2.42 GB) in 2m 41s, down from 2565508 KB (2.56 GB) in 2m 36s. I think the change in time is just noise from other programs on my system, rustc-perf will have more accurate times. |
Not sure when it went from 8.5 GB to 2.5 GB ... maybe I measured wrong at some point? |
2611304 (2.6 GB) on beta, 2645148 (2.6 GB) on stable. I think I'm measuring this wrong somehow. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit e852bb4bf1a8a460240a01474aaba58221cd9df1 with merge 7a00fa80319b87268f2e011e4d760b5ceabade92... |
Ok yes, I was measuring this wrong - the allocation in Without the changes (39b841d):
With the changes:
|
This should *vastly* reduce memory usage.
This was simpler than expected.
Rustfmt fails and I think your push canceled the try run. |
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 is an awesome PR! Thanks a lot for working on it. I just have one suggestion but you can ignore it if you feel that the current code is better, I have no strong preference here.
- Use a tuple struct instead of a single field - Enforce calling `source_callsite()` by making the inner span private - Rename `empty` to `dummy`
The current code looks good to me. I repeat myself but this is really an amazing PR, thanks a lot! r=me when CI pass. :) |
I want to see the perf improvement first, I like seeing green numbers 😆 |
Finished benchmarking try commit (c6c84e4efa0153524a3de2b6c65eac7adf1cc6e7): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Up to -2.4% on instructions, up to -3% on max-rss 🎉 🎉 @bors r=GuillaumeGomez |
📌 Commit 9684557 has been approved by |
☀️ Test successful - checks-actions |
Get rid of `clean::Deprecation` This brings the size of `item.deprecation` from 56 to 16 bytes. Helps with rust-lang#79103 and rust-lang#76382, in the same vein as rust-lang#79957. r? `@GuillaumeGomez`
Pass a `TyCtxt` through to `FormatRender` This is the next step after rust-lang#79957 for rust-lang#76382. Eventually I plan to use this to remove `stability`, `const_stability`, and `deprecation` from `Item`, but that needs more extensive changes (in particular, rust-lang#75355 or something like it). This has no actual changes to behavior, it's just moving types around. ccc rust-lang#80014 (comment)
This brings
size_of<clean::types::Span>()
down from over 100 bytes (!!) to only 12, the same as rustc. It bringsItem
down even more, from784
to680
.TODO: I need to figure out how to do this for the JSON backend too. That usesFigured it out, fortunately only two functions needed to be changed. I like theFrom
impls everywhere, which don't allow passing in theSession
as an argument. @P1n3appl3, @tmandry, maybe one of you have ideas?convert_x()
format better thanFrom
everywhere but I'm open to feedback.Helps with #79103