perf(ast/estree): ESTree serializer use CodeBuffer

[overlookmotel]

ESTree serializer use CodeBuffer to assemble JSON string. CodeBuffer has a more efficient push implementation than Vec<u8>.

[overlookmotel]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• perf(ast/estree): ESTree serializer use CodeBuffer #9331 👈 (View in Graphite)
• refactor(estree): make itoa dependency optional #9338
• feat(data_structures): add CodeBuffer::print_bytes_iter_unchecked method #9337
• refactor(data_structures): add debug assertion to CodeBuffer::peek_nth_char_back and improve safety docs #9336
• refactor(data_structures): CodeBuffer::print_str use Vec::extend_from_slice #9332 : 1 other dependent PR (#9335 )
• 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 #9331 will not alter performance

_{Comparing 02-23-perf_ast_estree_estree_serializer_use_codebuffer_ (2c8281a) with main (8bde4e3)}

Summary

✅ 33 untouched benchmarks

[Boshen]

No difference in performance?

[overlookmotel]

Only +0.5% improvement. Damn, I hoped for more.

I guess the improvement in perf of push is insignificant in context of the rest of the work the serializer does.

[Boshen]

Shall we reject the PR given the added dependency? oxc_data_structures will grow in size ... hence slower compile time overall due to oxc_ast -> oxc_estree -> oxc_data_structures.

[overlookmotel]

Personally I still think it's worthwhile, for 3 reasons:

1. CodeBuffer can be optimized further, and it'd be ideal to do that in one place, so both ESTree serialization and oxc_codegen both benefit.
2. This PR removes near-identical code from oxc_estree (Buffer was same thing as CodeBuffer, just with less thorough doc comments!).
3. There's a sizeable perf improvement in this PR to generation of pretty-printed JSON. We won't see that in benchmarks as they only use compact JSON serializer, but it should gain us a little bit on time to run conformance.

However, you're absolutely right about the dependency chain. I had overlooked that oxc_data_structures can be an optional dependency for oxc_estree. Have changed that now. So, unless serialize feature is enabled, it adds no dependencies to oxc_ast. (#9338 also makes itoa dependency optional - I'd also missed that before)

But I've moved this PR to the top of the stack, so that we can drop it if you feel strongly.