-
-
Notifications
You must be signed in to change notification settings - Fork 755
perf(transformer/using): avoid large types on stack #9676
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
perf(transformer/using): avoid large types on stack #9676
Conversation
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
CodSpeed Performance ReportMerging #9676 will create unknown performance changesComparing Summary
Benchmarks breakdown
|
camc314
left a comment
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.
thanks for the detail in the description!
c1c03c8 to
a4fed5a
Compare
8d255b1 to
2043688
Compare
Merge activity
|
a4fed5a to
786b7dc
Compare
Follow-on after #9310. Holding large types on the stack is generally best to avoid where possible. Get the data into the arena as quickly as possible, and then only need to pass around `Box`es (which are only 8 bytes). In the case of `Class`, previously we were `unbox`-ing a `Class` (pull it out of the arena, and onto the stack) and then allocating it back into the arena again. `Class` is a large type - 160 bytes - and this extra work doesn't add any value. We can just leave the `Class` where it is in the arena, and pass around a `Box<Class>`. This is something of a micro-optimization, but they all add up...
2043688 to
d06e5f2
Compare
786b7dc to
21859ca
Compare
Follow-on after #9310. Holding large types on the stack is generally best to avoid where possible. Get the data into the arena as quickly as possible, and then only need to pass around `Box`es (which are only 8 bytes). In the case of `Class`, previously we were `unbox`-ing a `Class` (pull it out of the arena, and onto the stack) and then allocating it back into the arena again. `Class` is a large type - 160 bytes - and this extra work doesn't add any value. We can just leave the `Class` where it is in the arena, and pass around a `Box<Class>`. This is something of a micro-optimization, but they all add up...
d06e5f2 to
36aa13d
Compare
Follow-on after #9310. Holding large types on the stack is generally best to avoid where possible. Get the data into the arena as quickly as possible, and then only need to pass around `Box`es (which are only 8 bytes). In the case of `Class`, previously we were `unbox`-ing a `Class` (pull it out of the arena, and onto the stack) and then allocating it back into the arena again. `Class` is a large type - 160 bytes - and this extra work doesn't add any value. We can just leave the `Class` where it is in the arena, and pass around a `Box<Class>`. This is something of a micro-optimization, but they all add up...
21859ca to
076d872
Compare
36aa13d to
15dd0d4
Compare

Follow-on after #9310.
Holding large types on the stack is generally best to avoid where possible. Get the data into the arena as quickly as possible, and then only need to pass around
Boxes (which are only 8 bytes).In the case of
Class, previously we wereunbox-ing aClass(pull it out of the arena, and onto the stack) and then allocating it back into the arena again.Classis a large type - 160 bytes - and this extra work doesn't add any value. We can just leave theClasswhere it is in the arena, and pass around aBox<Class>.This is something of a micro-optimization, but they all add up...