-
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
Shrink Expr_::ExprInlineAsm. #37445
Shrink Expr_::ExprInlineAsm. #37445
Conversation
On 64-bit this reduces the size of `Expr_` from 144 to 64 bytes, and reduces the size of `Expr` from 176 to 96 bytes.
cc @jseyfried Doing the same for the AST might speed up expansion. @bors r+ |
📌 Commit a920e35 has been approved by |
⌛ Testing commit a920e35 with merge f5a702d... |
Shrink Expr_::ExprInlineAsm. On 64-bit this reduces the size of `Expr_` from 144 to 64 bytes, and reduces the size of `Expr` from 176 to 96 bytes. For the workload in #36799 this reduces the RSS for the "lowering ast -> hir" phase and all subsequent phases by 50 MiB, which reduces the peak RSS for that workload by about 1%. Not huge, but it's a very easy improvement. r? @eddyb
I did some more measurements because the above improvement was smaller than expected. Massif showed that this change does make a decent difference. Here are measurements for a cut down version of ostn15_phf that peaks at ~1 GiB instead of ~4.5 GiB. Before:
After:
The I then did some RSS measurements of stage2 compilers via /usr/bin/time. They jump around a bit, but if I take the lowest of 3 runs, the before vs. after improvement is 1108 MB -> 1004 MB, which is a 9% drop. Good. In conclusion, I'm not sure what went wrong with my initial measurements, but I'm confident now that this reduces memory usage for ostn15_phf by about 9%. |
Nice wins. |
On 64-bit this reduces the size of
Expr_
from 144 to 64 bytes, andreduces the size of
Expr
from 176 to 96 bytes.For the workload in #36799 this reduces the RSS for the "lowering ast -> hir" phase and all subsequent phases by 50 MiB, which reduces the peak RSS for that workload by about 1%. Not huge, but it's a very easy improvement.
r? @eddyb