denoland-deno/ops/optimizer_tests/op_state_with_transforms.expected

=== Optimizer Dump ===
returns_result: false
has_ref_opstate: true
has_rc_opstate: false
has_fast_callback_option: false
needs_fast_callback_option: false
fast_result: Some(Void)
fast_parameters: [V8Value, Uint8Array]
transforms: {1: Transform { kind: SliceU8(true), index: 1 }}
is_async: false
fast_compatible: true
refactor(ops): Rewrite fast call optimizer and codegen (#16514) 2022-11-10 03:53:31 -08:00			`=== Optimizer Dump ===`
			`returns_result: false`
			`has_ref_opstate: true`
			`has_rc_opstate: false`
perf(ops): Reenable fast unit result optimization (#16827) The optimization was missed in the optimizer rewrite https://github.com/denoland/deno/pull/16514 2022-11-26 20:48:17 -08:00			`has_fast_callback_option: false`
perf(ops): Remove unnecessary fast call fallback options usage (#17585) Currently fast ops will always check for the alignment of a TypedArray when getting a slice out of them. A match is then done to ensure that some slice was received and if not a fallback will be requested. For Uint8Arrays (and WasmMemory which is equivalent to a Uint8Array) the alignment will always be okay. Rust probably optimises this away for the most part (since the Uint8Array check is `x % 1 != 0`), but what it cannot optimise away is the fast ops path's request for fallback options parameter. The extra parameter's cost is likely negligible but V8 will need to check if a fallback was requested and prepare the fallback call just in case it was. In the future the lack of a fallback may also enable V8 to much better optimise the result handling. For V8 created buffers, it seems like all buffers are actually always guaranteed to be properly aligned: All buffers seem to always be created 8-byte aligned, and creating a 32 bit array or 64 bit array with a non-aligned offset from an ArrayBuffer is not allowed. Unfortunately, Deno FFI cannot give the same guarantees, and it is actually possible for eg. 32 bit arrays to be created unaligned using it. These arrays work fine (at least on Linux) so it seems like this is not illegal, it just means that we cannot remove the alignment checking for 32 bit arrays. 2023-01-29 16:05:08 +02:00			`needs_fast_callback_option: false`
refactor(ops): Rewrite fast call optimizer and codegen (#16514) 2022-11-10 03:53:31 -08:00			`fast_result: Some(Void)`
			`fast_parameters: [V8Value, Uint8Array]`
			`transforms: {1: Transform { kind: SliceU8(true), index: 1 }}`
feat(ops): implement fast lazy async ops (#16579) Implements fast scheduling of deferred op futures. ```rs #[op(fast)] async fn op_read( state: Rc<RefCell<OpState>>, rid: ResourceId, buf: &mut [u8], ) -> Result<u32, Error> { // ... } ``` The future is scheduled via a fast API call and polled by the event loop after being woken up by its waker. 2022-11-11 05:44:53 -08:00			`is_async: false`
			`fast_compatible: true`