perf(core): op_baseline bench

[AaronO]

This PR introduces a benchmark that serves to measure the baseline-overhead of ops (or the per-category upper bound).

This should also serve to:

• Measure gains from refactor(core): new optimized op-layer using serde_v8 #9843 and follow-up PRs
• Prevent regressions

Output

~/git/deno/core bench/op-baseline
❯ cargo bench

...

running 3 tests
test bench_op_nop     ... bench:     603,784 ns/iter (+/- 102,433)
test bench_op_pi_bin  ... bench:     873,331 ns/iter (+/- 39,010)
test bench_op_pi_json ... bench:   3,210,314 ns/iter (+/- 290,248)

test result: ok. 0 passed; 0 failed; 0 ignored; 3 measured

Notes

• Each bench iter has 1000 JS loop-iterations, so divide by 1000 to have the true ns/op

[AaronO]

Here are the results of this bench on #9843:

test bench_op_nop     ... bench:     536,430 ns/iter (+/- 137,708)
test bench_op_pi_bin  ... bench:     779,053 ns/iter (+/- 30,542)
test bench_op_pi_json ... bench:     675,587 ns/iter (+/- 23,755)

[ry]

Looks good.

Will bin ops exist after #9843?

[AaronO]

@ry They'll still exist immediately after #9843, since I wanted to limit code changes outside of core/.

It would now be trivial to collapse all our ops and have only core.opAsync, core.opSync. But I think it may be worth keeping them around as abstractions, not as implementations, as mentioned in #9843's Key Ideas:

Preserve concepts of json/bin/min as semantic groups of their inputs/outputs instead of their op-encoding strategy, preserving these groups will also facilitate partial transitions over to v8 Fast API for the "min" and "bin" groups

Talking with @bartlomieju, he seemed eager to collapse the extra abstractions. But I think our diverging views may stem from the fact that he associates bin-ops with the implementation and its technical debt, but given that I'm fairly new to deno it's easier to dissociate the abstraction/semantic-group from the implementation.

[bartlomieju]

LGTM