Fix mangler benchmarks and speed up the mangler

[overlookmotel]

The mangler benchmarks are extremely noisy, often reporting +/- 15% perf differences on PRs which don't touch the mangler at all. The mangler[cal.com.tsx] benchmark is the worst offender, but other mangler benchmarks are also displaying a lot of variance.

Presumably the source of this variance is unpredictable patterns of allocation.

The mangler already uses an Allocator internally for storing some temporary data. I suggest we try to put more of the temporary Vecs and HashMaps used in the mangler into this arena too. That should make the pattern of allocations more deterministic, and so reduce the variance in benchmarks. I would hope it may also be a performance gain, as it'll reduce allocations overall.

One note: When storing data in an arena, it becomes much more important to accurately predict upfront how large a Vec / HashMap is going to get, and reserve sufficient capacity when creating the Vec / HashMap.

Reserving sufficient capacity upfront is always a gain, because growing these structures is an expensive operation, especially if they're large. But when the Vec / HashMap is stored in an arena, it becomes even more important. When Vec / HashMap is stored on general heap, sometimes the OS can grow the allocation in place (very cheap), or resize it by altering the page table (somewhat cheap). But when the Vec / HashMap is in an arena, neither of these is an option, and growth always results in creating a new allocation and copying all the data from the old allocation to the new one (very expensive).

[overlookmotel]

Actually, looking flame graphs on CodSpeed for PRs which report ~15% regression on mangler[cal.com.tsx] benchmarks, the main source of the variance is allocating memory for the Allocator used for temp allocations (bumpalo::Bump::alloc_layout), and this is really expensive in the context of the mangler.

e.g.: https://codspeed.io/oxc-project/oxc/branches/05-26-perf_parser_remove_branch_parsing_class_elements

What we should ideally do is: Instead of creating a fresh Allocator inside the mangler each time, create one outside and pass in &Allocator. After mangling one file, that Allocator can be reset and then re-used when mangling the next file. This would both remove the benchmark variance, and speed up the mangler a lot.

Note: This is the same pattern we use when parsing and transforming multiple files. The parser is provided an &Allocator which it stores the AST in. Once we're done with that file, that allocator is reset and reused for the next file, rather than creating a new Allocator each time.

The question is: How to make this ergonomic for the user? Having to create two allocators and pass the right one into various methods is confusing and annoying!

[camchenry]

@overlookmotel I briefly tried to make a fix here: #11408, though I wasn't sure what the right approach with the allocators is. Do we want to use two separate allocators? Is re-using the same allocator that we just used for the parser a bad idea for performance / memory?

[overlookmotel]

Our attempts to reduce the benchmark variance have had no success so far (though they did improve the mangler's performance).

#12118 disables the benchmarks until we can figure out how to fix it.

[Boshen]

Reverted in bc0b471

[Boshen]

Theres some huge memory allocations happening for

        let mut slot_liveness: std::vec::Vec<FixedBitSet> = vec![];

                slot_liveness
                    .resize_with(slot, || FixedBitSet::with_capacity(scoping.scopes_len()));

But we can't allocate it in arena

error[E0080]: evaluation panicked: Cannot create a Vec<T> where T is a Drop type
  --> /home/runner/work/oxc/oxc/crates/oxc_allocator/src/vec.rs:61:9
   |
61 |         assert!(!std::mem::needs_drop::<T>(), "Cannot create a Vec<T> where T is a Drop type");
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ evaluation of `oxc_allocator::Vec::<'_, fixedbitset::FixedBitSet>::ASSERT_T_IS_NOT_DROP` failed here

impl Drop for FixedBitSet {
    fn drop(&mut self) {
        // SAFETY: The data pointer and capacity were created from a Vec initially. The block
        // len is identical to that of the original.
        drop(unsafe {
            Vec::from_raw_parts(self.data.as_ptr(), self.simd_block_len(), self.capacity)
        });
    }
}

Attempt: #13353

[overlookmotel]

I mentioned this in #11409 (review).

Yes, it's a Vec of Vecs, so would be ideal to store in an arena. But FixedBitSet stores its data on the heap, so we can't do that without memory leaks (that's why it's refusing to compile).

We'd need to either:

1. Request that FixedBitSet support custom allocators via allocator_api2 (not an unreasonable ask IMO). or
2. Reimplement FixedBitSet in Oxc, using an oxc_allocator::Vec internally.

We probably only need a subset of FixedBitSet's functionality, so reimplementing it might not be too hard. Unless we're using any of its SIMD-accelerated features, which would be pretty difficult to fold into Oxc, as we don't have the testing infra to make sure it works on all platforms and all of SSE2/AVX/AVX2/AVX512 etc.

Trying to get custom allocator support upstream is probably the easier option.