perf(allocator/vec2): optimize reserving memory

[Dunqing]

resolve: #9656 (comment)

#9656 brought a small performance improvement for the transformer but also led the parser to 1% performance hits. This PR returns performance by splitting reserve_internal to reserve_exact_internal and reserve_amortized_internal respectively the internal implementation of reserve_exact and reserve.

Why the change can improve performance?

The original reserve_internal implementation has a check for reserve strategy,

oxc/crates/oxc_allocator/src/vec2/raw_vec.rs

Lines 664 to 668 in fef680a

	// Nothing we can really do about these checks :(
	let new_cap = match strategy {
	Exact => used_cap.checked_add(needed_extra_cap).ok_or(CapacityOverflow)?,
	Amortized => self.amortized_new_size(used_cap, needed_extra_cap)?,
	};

which is can be avoided because the caller of reserve_internal already knows the reserve strategy. After the change, the reserve_exact and reserve can call the corresponding internal implementation directly, which can avoid unnecessary checks.

Likewise, the Fallibility check can also be avoided,

oxc/crates/oxc_allocator/src/vec2/raw_vec.rs

Lines 681 to 683 in fef680a

	if let (Err(AllocError), Infallible) = (&res, fallibility) {
	handle_alloc_error(new_layout);
	}

because we know where the errors should be handled.

Due to this change, I also replaced Bumpalo's CollecitonAllocErr with allocator-api2's TryReserveError because CollecitonAllocErr::AllocErr cannot pass in a Layout. I ended up reverting 937c61a as it caused transformer performance 1%-2% regression (See codspeed and switch to "replace CollectionAllocErr with TryReserveError" commit), and replaced by 84edacd I've tried various way to save the performance but it not work. I suspect the cause is that TryReserveError is 16 bytes whereas CollecitonAllocErr is only 1 byte.

So, after both checks are removed, the performance returns to the original. The whole change is according to standard RawVec's implementation. See https://doc.rust-lang.org/src/alloc/raw_vec.rs.html

[Dunqing]

• perf(allocator/vec2): optimize reserving memory #9792 👈 (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 Performance Report

Merging #9792 will not alter performance

_{Comparing 03-15-pref_allocator_vec2_optimize_reserving_memory (17a9320) with main (e924c2b)}

Summary

✅ 33 untouched benchmarks

[overlookmotel]

Excellent!

[overlookmotel]

Merge activity

• Mar 17, 8:25 AM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Mar 17, 8:26 AM EDT: A user added this pull request to the Graphite merge queue.
• Mar 17, 8:32 AM EDT: A user merged this pull request with the Graphite merge queue.