-
Notifications
You must be signed in to change notification settings - Fork 13.5k
Shrink Expr_::ExprInlineAsm. #37445
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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