perf(transformer): optimize inserting var/let statements

[Dunqing]

Found while working on #9881, this PR aims to optimize inserting statements by reducing an unnecessary Vec allocation.

Previously, get_var_statement would collect var statement and let statement into a std::vec::Vec and return it, then immediately extend/insert to another ArenaVec. Considering here only have two elements, we don't need to store them in a Vec, just return them, and use them depending on how they are used.

Seems to have very minor improvement, and I guess transformer/checker.ts has 0.1 regression is noisy.

[Dunqing]

• perf(allocator/vec2): align min amortized cap size with std #9857
• feat(allocator/vec2): align RawVec::reserve with standard library implementation #10701
• perf(allocator/vec2): replace self.reserve(1) calls with self.grow_one() for better efficiency #9856
• feat(allocator/vec2): add specialized grow_one method #9855
• perf(allocator/vec2): calling Bump::grow or Bump::shrink at the call site directly instead of calling realloc #10686
• perf(allocator/vec2): resolve performance regression for extend by marking reserve as #[cold] and #[inline(never)] #10675
• feat(allocator/vec2): introduce extend_desugared method as extend internal implementation #10670
• perf(transformer/refresh): use take/take_in instead of drain #10656
• perf(transformer): optimize inserting var/let statements #10654 👈 (View in Graphite)
• 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 #10654 will not alter performance

_{Comparing 04-28-perf_transformer_optimize_inserting_var_let_statements (91df9d4) with main (4825eb5)}

Summary

✅ 36 untouched benchmarks

[overlookmotel]

It's definitely an improvement not to allocate a temp Vec.

What is less good is that we always copy the whole of stmts into a new ArenaVec. If stmts has spare capacity, it'd be preferable to shift up the existing Statements to make room for the new ones at the start, and then move the new statements into the newly-created space. That doesn't reduce the amount of memory copying that needs to happen, but at least it does it without consuming more memory in arena for a brand new Vec.

However, I was surprised to see that Vec::splice was doing the same unoptimal thing - allocate a new Vec and copy everything over. Vec::insert is also surprisingly bad! If the Vec is already full to capacity, it copies all the existing elements of the Vec twice, which is completely unnecessary.

To get this (and the many similar operations in our code) optimal, we'd need new APIs like:

impl<'a, T> Vec<'a, T> {
    /// Same as `vec.insert(0, value)`
    fn push_start(&mut self, value: T);
    /// Same as `vec.splice(0..0, iter)`
    fn extend_start<I: IntoIterator<Item = T>>(&mut self, iter: I);
}

We could optimize these to use the "shift up" method.

[overlookmotel]

Merge activity

• Apr 29, 12:00 PM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Apr 29, 12:00 PM EDT: overlookmotel added this pull request to the Graphite merge queue.
• Apr 29, 12:09 PM EDT: Merged by the Graphite merge queue.