Discovered in 0xMiden/compiler#625
The add_asset_to_note return parameters handling adds extra overhead when called from Rust code.
It returns the asset and note_idx (see code). When called from Rust, they are expected to be returned via a pointer (C-ABI, see Rust bindings). So we have to store the result (asset and note idx) into memory. See the compiled code from the basic-wallet example
But the returned results are most likely not going to be used in Rust code since they are the same as the parameters, everyone will just reuse/clone parameters. So we're effectively running this extra code for nothing.
I wondered if the add_asset_to_note API is optimized for MASM to avoid duplicating the elements on the stack when called in a loop. If so, then we're paying a very high price for it in Rust. I saw this pattern (returning parameters) in other functions in the miden-base.
Discovered in 0xMiden/compiler#625
The
add_asset_to_notereturn parameters handling adds extra overhead when called from Rust code.It returns the asset and note_idx (see code). When called from Rust, they are expected to be returned via a pointer (C-ABI, see Rust bindings). So we have to store the result (asset and note idx) into memory. See the compiled code from the basic-wallet example
But the returned results are most likely not going to be used in Rust code since they are the same as the parameters, everyone will just reuse/clone parameters. So we're effectively running this extra code for nothing.
I wondered if the
add_asset_to_noteAPI is optimized for MASM to avoid duplicating the elements on the stack when called in a loop. If so, then we're paying a very high price for it in Rust. I saw this pattern (returning parameters) in other functions in themiden-base.