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.
Add a quick benchmark for NAPI parser. It's included in our CI benchmarks, because likely will produce too much variance, but it's useful for local runs.
- Added TypeScript annotation for `ParseResult.program`
- Modified the entrypoint for `oxc-parser` to allow wrapping the napi functions
- Updated `index.js` to parse the `program` string into a JSON object
- Updated tests
- Added a dependency on `@oxc/types`
Add NodeJS parser to benchmarks.
Previous attempt #2724 did not work due CodSpeed producing very
inaccurate results (https://github.com/CodSpeedHQ/action/issues/96).
This version runs the actual benchmarks without CodSpeed's
instrumentation. Then another faux-benchmark runs within Codspeed's
instrumented action and just performs meaningless calculations in a loop
for as long as is required to take same amount of time as the original
uninstrumented benchmarks took.
It's unfortunate that we therefore don't get flame graphs on CodSpeed,
but this seems to be the best we can do for now.
Closes#2616.
Adds benchmarks for NodeJS NAPI build. Measurement includes `JSON.parse`
of the AST on JS side, since that's how it'll be used 99% of the time.
Benchmarks run against same files as Rust parser benchmarks, so we can
see the overhead of transferring AST to JS.
Hi! I have created a proof of concept of improving using oxc in
JavaScript. The method is not polished but it provides valuable insights
for future direction!
Feel free to close~ It is for reference only :)
# Context
This is a proof of concept implementation of passing binary AST to
JavaScript. JavaScript can selectively read flexbuffers-based AST nodes
on demand to avoid the deserialization toll. More context
[here](https://dev.to/herrington_darkholme/benchmark-typescript-parsers-demystify-rust-tooling-performance-2go8).
# Changes
* Add a `parseSyncBuffer` napi method to return a binary AST from Rust
to JavaScript. The AST is in flexbuffer format.
* Add a `test_buffer.js` to test usage of flexbuffers in JavaScript. It
is in cjs format because flexbuffers does not support ESM :/
# Result
Some preliminary results, for reference only.
```
~ node test_buffer.js
testJSON: 4.043s
testBuffer: 2.395s
```
Buffer based API is 100% faster than JSON.
# Future Ideas
* Flexbuffers itself is slow. A better binary protocol is desired!
* Using binary reader to traverse AST is undesirable. A proxy-based API
to emulate object behavior will be nice.
oxc-bot