perf: reduce stack mem-move

[h-a-n-a]

Summary

Test Plan

Related issue (if exists)

How does Webpack handle this? (if exists)

Is this a workaround for the Webpack's implementation?

Check if Webpack has the same feature and but we're taking a workaround for it.

• Yes. Issue for resolving the workaround:
• No

Further reading

[changeset-bot]

⚠️ No Changeset found

Latest commit: ba67ffe

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[h-a-n-a]

!bench

[github-actions]

Benchmark Results

group                                                 baseline                               pr
-----                                                 --------                               --
criterion_benchmark/css_heavy                         1.00     45.3±2.31ms        ? ?/sec    1.01     45.8±2.51ms        ? ?/sec
criterion_benchmark/lodash                            1.00     69.6±0.99ms        ? ?/sec    1.01     70.1±0.95ms        ? ?/sec
criterion_benchmark/ten_copy_of_threejs               1.00    729.4±5.53ms        ? ?/sec    1.01    738.1±5.61ms        ? ?/sec
high_cost_benchmark/ten_copy_of_threejs_production    1.00       4.7±0.01s        ? ?/sec    1.00       4.7±0.01s        ? ?/sec

[Boshen]

FYI box keyword / box pattern is perma-unstable rust-lang/rust#49733 (comment)

[h-a-n-a]

I intended to place the item in the box to the heap directly. There are some places that used this, if the syntax changes, I will update this.

[hyf0]

How do we measure the cost of stack mem-move?

[h-a-n-a]

How do we measure the cost of stack mem-move?

@hyf0 Theoretically, for an AST contains huge nodes, it will improve.

[IWANABETHATGUY]

According to perf book

Furthermore, Rust types that are larger than 128 bytes are copied with memcpy rather than inline code. If memcpy shows up in non-trivial amounts in profiles, DHAT’s “copy profiling” mode will tell you exactly where the hot memcpy calls are and the types involved. Shrinking these types to 128 bytes or less can make the code faster by avoiding memcpy calls and reducing memory traffic.

Only struct bigger than 128bytes this perf is meaningful, would you mind double checking the type size of struct?

[h-a-n-a]

According to perf book

Furthermore, Rust types that are larger than 128 bytes are copied with memcpy rather than inline code. If memcpy shows up in non-trivial amounts in profiles, DHAT’s “copy profiling” mode will tell you exactly where the hot memcpy calls are and the types involved. Shrinking these types to 128 bytes or less can make the code faster by avoiding memcpy calls and reducing memory traffic.

Only struct bigger than 128bytes this perf is meaningful, would you mind double checking the type size of struct?

@IWANABETHATGUY I missed the fact that almost every huge node downstream are already being boxed, so this results in this optimization being trivial.