perf(transformer/object_rest_spread): use ArenaVec to store values that will be used in constructing AST

[Dunqing]

props is always used in expression_object without intermediate changes, so it is okay and good to use ArenaVec store, which also can avoid an unnecessary allocation (std vec -> arena vec converison).

[Dunqing]

• perf(minifier/minimize_statements): reduce allocations of Vec #10435 : 2 dependent PRs (#9881 , #10436 )
• perf(transformer/object_rest_spread): use ArenaVec to store values that will be used in constructing AST #10434 👈 (View in Graphite)
• perf(transformer/class-properties): return early if no private fields are found #10418
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

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-hq]

CodSpeed Instrumentation Performance Report

Merging #10434 will not alter performance

_{Comparing 04-16-perf_transformer_object_rest_spread_use_arenavec_to_store_values_that_will_be_used_in_constructing_ast (595c5df) with main (ebe3496)}

Summary

✅ 36 untouched benchmarks

[overlookmotel]

Merge activity

• Apr 16, 7:47 AM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Apr 16, 9:28 AM EDT: overlookmotel added this pull request to the Graphite merge queue.
• Apr 16, 9:42 AM EDT: Merged by the Graphite merge queue.

[overlookmotel]

There's something cool we could do here with our new Vec implementation.

We could add an API Vec::split_at which converts a Vec into 2 x Vecs, without copying any data or making any allocations.

let original_len = vec.len();
let original_ptr = vec.as_ptr();

let (vec1, vec2) = vec.split_at(2).unwrap();

assert!(vec1.len() == 2);
assert!(vec2.len() == original_len - 2);
// `vec1` and `vec2` point to chunks of the original `vec`
assert!(vec1.as_ptr() == original_ptr);
assert!(vec2.as_ptr() == original_ptr.add(2));

std's Vec cannot offer this API because when a Vec is dropped, it must deallocate with the same layout as it was originally allocated with. But because our Vec is not Drop, we don't have that restriction.

Using split_at, this transform could avoid copying any of the data from original Vec into new Vecs. It'd just create a bunch of Vecs which reference chunks of the original's data.

[Dunqing]

There's something cool we could do here with our new Vec implementation.

We could add an API Vec::split_at which converts a Vec into 2 x Vecs, without copying any data or making any allocations.

let original_len = vec.len();
let original_ptr = vec.as_ptr();

let (vec1, vec2) = vec.split_at(2).unwrap();

assert!(vec1.len() == 2);
assert!(vec2.len() == original_len - 2);
// `vec1` and `vec2` point to chunks of the original `vec`
assert!(vec1.as_ptr() == original_ptr);
assert!(vec2.as_ptr() == original_ptr.add(2));

std's Vec cannot offer this API because when a Vec is dropped, it must deallocate with the same layout as it was originally allocated with. But because our Vec is not Drop, we don't have that restriction.

Using split_at, this transform could avoid copying any of the data from original Vec into new Vecs. It'd just create a bunch of Vecs which reference chunks of the original's data.

That's cool! Maybe a dumb question, what scenario do you want to use this API for? In terms of the PR changes, we don't need to use vec1, so it looks like we should have a method like cut_off?

let original_vec = vec![1, 2, 3, 4, 5];
let cut_vec = vec.cut_off(2).unwrap();

assert!(original_vec.len() == 2);
assert!(cut_vec.len() == 3);
assert!(cut_vec.as_ptr() == original_vec.as_ptr().add(2));

[overlookmotel]

Yes, you're right. All we need is to optimize Vec::split_off (which is the existing method which is the same as your cut_off). I've updated oxc-project/backlog#161.