ci(benchmarks): benchmark NAPI parser

[overlookmotel]

Add benchmarks for NAPI parser. Benchmarks cover both "standard" mode and "raw transfer" mode.

Codspeed say they've sorted out the problems with wide variance in NodeJS benchmarks, so hopefully they won't wave all over the place, the way they did last year when we first tried to add these benchmarks.

What we also found last year is that Codspeed's measures didn't reflect real-world wallclock measurements at all when comparing code running on Rust side vs JS side. Raw transfer moves a lot of work from Rust side to JS side, and so likely the bench results will be misleading if comparing "standard" vs "raw".

I've added benchmarks for both, not to compare the 2, but because I think there's room to improve the performance of both "standard" and "raw" independently.

[overlookmotel]

• perf(mangler): use shorter InlineString #9552
• refactor(ast/estree): simplify serializing RegExpLiterals #9551
• perf(ast, codegen, transformer): avoid allocations when converting RegExpFlags to string #9550
• feat(data_structures): move InlineString into oxc_data_structures crate #9549
• refactor(ast): RegExpFlags::to_string return flags in alphabetical order #9548
• feat(ast/estree): Property have consistent field order #9547
• feat(ast/estree): ESTree AST ExportNamedDeclaration always have attributes field #9546
• ci(benchmarks): benchmark NAPI parser #9519 👈 (View in Graphite)
• fix(ast/estree): raw transfer support showSemanticErrors option #9522
• test(ast/estree): speed up raw transfer tests #9521
• feat(ast/estree)!: option to return JS-only AST #9520
• feat(ast/estree): raw transfer (experimental) #9516
• 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 #9519 will not alter performance

_{Comparing 03-03-ci_benchmarks_benchmark_napi_parser (a9889f5) with main (0a5c73b)}

Summary

✅ 33 untouched benchmarks
🆕 6 new benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
🆕	parser_napi[RadixUIAdoptionSection.jsx]	N/A	4.7 ms	N/A
🆕	parser_napi[pdf.mjs]	N/A	1.8 s	N/A
🆕	parser_napi_raw[RadixUIAdoptionSection.jsx]	N/A	1.3 ms	N/A
🆕	parser_napi_raw[cal.com.tsx]	N/A	699.4 ms	N/A
🆕	parser_napi_raw[checker.ts]	N/A	1.1 s	N/A
🆕	parser_napi_raw[pdf.mjs]	N/A	266.2 ms	N/A

[overlookmotel]

These benchmarks are really slow. I've skipped the worst ones, and sharded all the rest. But still should use a filter to skip running them unless relevant files have been touched. I'll look into that.

[overlookmotel]

Argh. We can't skip these benchmarks conditionally as it'll foul up CodSpeed. Every PR that doesn't touch NAPI parser would get a "dropped benchmarks" warning.

I've reached out to Codspeed to ask if possible to allow benchmarks to be intentionally skipped, and they've put it on their issue tracker. But who knows how long it'll take.

We may need to take matters into our own hands and build something to skip benchmarks when their dependences haven't changed, and submit the previous benchmark run's results in its place to keep Codspeed happy (oxc-project/backlog#3).

But in the meantime, I think we do need benchmarks for NAPI parser, as I'm going to be working on optimizing it. I've skipped the slowest ones, so they all complete faster than the linter benchmarks anyway.

[graphite-app]

Merge activity

• Mar 4, 9:04 PM EST: A user added this pull request to the Graphite merge queue.
• Mar 4, 9:30 PM EST: A user merged this pull request with the Graphite merge queue.