You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, standard.wat has a lot of functions (even basic ones) that calls subfunctions in their execution.
For example,
add-int and add-uint call the generic add-int128.
mul-int calls mul-uint, which calls mul-int128.
sha256-buffer calls multiple functions to keep it simple and clean.
...
Problem is that those calls add up, and could become expensive. A simple solution here would be to run wasm-opt -O4 after the compilation from wat to wasm.
wasm-opt is a tool from binaryen, which is a part of the official Webassembly organization.
wasm-opt exists as a CLI tool, but exists also as a crate here: wasm-opt. This crate is (at the time of writing) two versions below the official tool.
The text was updated successfully, but these errors were encountered:
As long as we can run our test suite against the optimized version and ensure that nothing "broke" in the process then I think that sounds like a good idea, assuming it doesn't affect size negatively too much (since the current theory is compiling the stdlib into each individual Clarity contract).
Currently, standard.wat has a lot of functions (even basic ones) that calls subfunctions in their execution.
For example,
add-int
andadd-uint
call the genericadd-int128
.mul-int
callsmul-uint
, which callsmul-int128
.sha256-buffer
calls multiple functions to keep it simple and clean.Problem is that those calls add up, and could become expensive. A simple solution here would be to run
wasm-opt -O4
after the compilation from wat to wasm.wasm-opt
is a tool from binaryen, which is a part of the official Webassembly organization.wasm-opt
exists as a CLI tool, but exists also as a crate here: wasm-opt. This crate is (at the time of writing) two versions below the official tool.The text was updated successfully, but these errors were encountered: