perf(ops): Monomorphic sync op calls

[aapoalas]

Welcome to better optimised op calls! Currently opSync is called with parameters of every type and count. This most definitely makes the call megamorphic. Additionally, it seems that spread params leads to V8 not being able to optimise the calls quite as well (apparently Fast Calls cannot be used with spread params).

Monomorphising op calls should lead to some improved performance. Now that unwrapping of sync ops results is done on Rust side, this is pretty simple:

opSync("op_foo", param1, param2);
// -> turns to
ops.op_foo(param1, param2);

This means sync op calls are now just directly calling the native binding function. When V8 Fast API Calls are enabled, this will enable those to be called on the optimised path.

Monomorphising async ops likely requires using callbacks and is left as an exercise to the reader.

Performance

Comparison of nop op in a vacuum:

running 2 tests
test bench_op_nop        ... bench:      37,315 ns/iter (+/- 5,121)
test bench_op_nop_opSync ... bench:      37,925 ns/iter (+/- 4,071)

Comparison of FFI related ops:

benchmark                            time (avg)             (min … max)
-----------------------------------------------------------------------
ops.op_ffi_cstr_read(ptr)        121.16 ns/iter  (102.2 ns … 249.56 ns)
opSync('op_ffi_cstr_read', ptr)   131.3 ns/iter (111.42 ns … 302.48 ns)
ops.op_ffi_ptr_of(buf)           140.96 ns/iter (125.56 ns … 246.76 ns)
opSync('op_ffi_ptr_of', buf)     184.02 ns/iter (162.43 ns … 411.55 ns)

Discussion

There are good things about this:

1. Performance
2. Picking the fruits created by the ops macro PR.

Downsides are:

1. None

[ghost]

If it makes it easier to get a first iteration done here, IMO it's reasonable to just do a swift inlining pass that ignores eluding unwrapOpResult.

[aapoalas]

If it makes it easier to get a first iteration done here, IMO it's reasonable to just do a swift inlining pass that ignores eluding unwrapOpResult.

Yeah, I think a lot of the files I'll just be doing that.

[aapoalas]

So, apparently this is ready for review and merge if nothing out of order is found. The tests failed once in parsing strace output but the failure did not repeat on another go around, so apparently it was a flake.

[littledivy]

love it!

[bartlomieju]

LGTM, thank you @aapoalas, great work