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
This might sound like a super stupid question but I am here to ask if the usage of Binaryen's wasm-opt specifically is production ready?
We have a great deal of motivation to use it to further optimize our Wasm binaries (produced by the Rust compiler mainly) since wasm-opt seems to do a really good job at this. For instance it was capable of reducing the size of an already Rust-optimized Wasm binary from 27kB to roughly 9kB which is nice because it means that we do not have to introduce certain work arounds on the Rust code in order to improve the resulting code quality. However, we are unsure if the optimizations done by wasm-opt are "guaranteed" to not break or slightly change semantics of the optimized code. Of course, this is a declared anti-goal of every optimizer, however, if this is a real constraint for production usage: Would you still recommend Binaryen's wasm-opt for this use-case?
The text was updated successfully, but these errors were encountered:
Robbepop
changed the title
Question: Production Ready?
Question: Is wasm-opt production ready?
Jan 31, 2020
Yes, definitely! Being robust and production-ready is a top priority in wasm-opt. We test it very heavily with our own internal test suite, the emscripten test suite, and using fuzzing. It is used by many people in production (anything using emscripten uses it, for example).
(wasm-opt does have optional optimizations that may change semantics; those would not be turned on by default, of course.)
This might sound like a super stupid question but I am here to ask if the usage of Binaryen's
wasm-opt
specifically is production ready?We have a great deal of motivation to use it to further optimize our Wasm binaries (produced by the Rust compiler mainly) since
wasm-opt
seems to do a really good job at this. For instance it was capable of reducing the size of an already Rust-optimized Wasm binary from 27kB to roughly 9kB which is nice because it means that we do not have to introduce certain work arounds on the Rust code in order to improve the resulting code quality. However, we are unsure if the optimizations done bywasm-opt
are "guaranteed" to not break or slightly change semantics of the optimized code. Of course, this is a declared anti-goal of every optimizer, however, if this is a real constraint for production usage: Would you still recommend Binaryen'swasm-opt
for this use-case?The text was updated successfully, but these errors were encountered: