-
-
Notifications
You must be signed in to change notification settings - Fork 641
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
|
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
Box
es (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.Class
is a large type - 160 bytes - and this extra work doesn't add any value. We can just leave theClass
where it is in the arena, and pass around aBox<Class>
.This is something of a micro-optimization, but they all add up...