• perf(allocator/vec2): align min amortized cap size with std #9857 👈 (View in Graphite)
• 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
• 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.

This stack of pull requests is managed by Graphite. Learn more about stacking.

CodSpeed Instrumentation Performance Report

Merging #9857 will not alter performance

_{Comparing 03-18-perf_allocator_vec2_align_min_amortized_cap_size_with_std (4eaef66) with main (7f2f247)}

Summary

✅ 36 untouched benchmarks

Merge activity

• May 3, 10:33 AM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• May 3, 10:52 AM EDT: overlookmotel added this pull request to the Graphite merge queue.
• May 3, 11:11 AM EDT: Merged by the Graphite merge queue.

@Dunqing This is a really interesting discovery that Vecs having a minimum capacity of 4 is a perf regression for oxc_transformer etc (it'd be 4 for all AST types, as they're all between 8 and 1024 bytes).

I suspect that the reason isn't the cost of the cmp::max call in grow_amortized (like your comment says), but is to do with CPU cache usage.

As you say, many Vecs in AST require less than 4 elements e.g. the Vec<FormalParameter> in function foo(x) {}. FormalParameter is 80 bytes, so if there's spare capacity of 3 in the Vec, that results in 240 bytes unused in the middle of the arena. With data spread out across the arena, it'll produce more L1/L2 cache misses when traversing the AST.

That's just a theory, but I doubt one cmp::max call could produce a significant perf regression, especially as it's on a cold path.

I agreed your point! I've tried to pre-allocate 4 or 8 capacity for most of Vec usages in the parser, the benchmark result surprised me, it doesn't improve but hurts 1%-2% performance. The reason is probably like you said.