-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Box the biggest ast::ItemKind variants #81405
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
@bors try @rust-timer queue |
Awaiting bors try build completion. |
⌛ Trying commit 7b379a25a2ac7d8dd3508f73e5cdec3e8a34452d with merge 7fc85fb97c995b5a91e77a8c4addcd865da24d11... |
☀️ Try build successful - checks-actions |
Queued 7fc85fb97c995b5a91e77a8c4addcd865da24d11 with parent 1483e67, future comparison URL. @rustbot label: +S-waiting-on-perf |
Finished benchmarking try commit (7fc85fb97c995b5a91e77a8c4addcd865da24d11): 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 |
Wait, what did I do to make typeck faster? I thought that works on the HIR and not the AST o.O Anyway, small runtime improvement and a disappointing lack of improvement in max-rss. In comparison, a bit less perf gain than #81400, but opposed to that this is at least not completely red on memory. |
@bors try @rust-timer queue |
Awaiting bors try build completion. |
⌛ Trying commit ff464fe5d23cee78979bf8669c8c83ef7ffcb2b7 with merge bf1b6dbd7f67fc51be6c4ba42a6d0d25a6fa9a3b... |
☀️ Try build successful - checks-actions |
Queued bf1b6dbd7f67fc51be6c4ba42a6d0d25a6fa9a3b with parent 613ef74, future comparison URL. @rustbot label: +S-waiting-on-perf |
Finished benchmarking try commit (bf1b6dbd7f67fc51be6c4ba42a6d0d25a6fa9a3b): 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 |
Perf is largely the same as before, max-rss maybe a bit better (uh, less terrible?) if you squint real hard, but that can always be noise. |
I undid most of the clippy formatting changes (thanks, RA), and I declare this ready for review. |
☔ The latest upstream changes (presumably #81560) made this pull request unmergeable. Please resolve the merge conflicts. |
Can you add a |
} | ||
|
||
#[derive(Clone, Encodable, Decodable, Debug)] | ||
pub struct FnKind(pub Defaultness, pub FnSig, pub Generics, pub Option<P<Block>>); |
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.
Should these new structs have named fields?
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.
Honestly, I'm undecided. These were fine without before, and adding names would just bloat up a lot of match patterns. If we were to start replacing them here, we could go through the whole codebase and replace like two million tuple structs as well.
Sure, but I'm not sure if the structs have the same size on 32bit platforms - wouldn't that be an issue, either now or later? |
They wouldn't be the same. In Precision: #[cfg(target_arch = "x86_64")]
rustc_data_structures::static_assert_size!(hir::Expr<'static>, 72); |
@cjgillot I've added asserts (to the enums, because it's their sizes we want to keep low to avoid wasting memory for the "smaller" variants), and I've updated the PR with the size changes. There are two more possibilities for the near future, based on this PR: While gathering the sizes, I've noticed that some of the smaller variants in Also, #81400 showed that perf-wise there is not much difference between boxing a few variants vs boxing the whole enum. Since this PR aims at saving memory, I'll check if it's worth taking the current approach to the extremes and making |
@bors r+ rollup=never |
📌 Commit 003fba3 has been approved by |
☀️ Test successful - checks-actions |
Box the biggest ast::ItemKind variants This PR is a different approach on rust-lang#81400, aiming to save memory in humongous ASTs. The three affected item kind enums are: - `ast::ItemKind` (208 -> 112 bytes) - `ast::AssocItemKind` (176 -> 72 bytes) - `ast::ForeignItemKind` (176 -> 72 bytes)
This PR is a different approach on #81400, aiming to save memory in humongous ASTs.
The three affected item kind enums are:
ast::ItemKind
(208 -> 112 bytes)ast::AssocItemKind
(176 -> 72 bytes)ast::ForeignItemKind
(176 -> 72 bytes)