-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a dedicated page about optimizing for speed #154
Comments
I agree! when building sandspiel, i had no idea about the opt-level, and performance improved a lot with very little bundle size cost when i switched from one question I would have from this section is, when doing performance analysis, is it safe to measure the performance of my code using criterion and running as native rust? Or are there large enough differences between the performance characteristics of the same code compiled to wasm vs native targets that this is a bad idea? Can I run criterion in a browser test? |
It should generally be ok, in that a big speed up on native should generally translate to a big speed up on wasm. You'll (obviously) get a more accurate picture of perf in wasm when running on wasm, and I'm sure there are edge cases where wasm engines add more relative overhead to an indirect call (for example) than the equivalent native code would have. But in my experience, I have found that profiling on native and seeing a speed up there translates to a speed up in wasm. |
thanks @fitzgen, that makes good sense. and nice work in your fork there! :o |
Most of our default templates and such are all listed as optimizing for code size, and the current book also has extensive documentation about how to shrink a wasm binary. This makes sense as it's one of the most common inquiries we get!
On the other hand, however, the recommendations that we make can come at a severe runtime performance cost. To that end I think we'll also want to make sure there's dedicated documentation for how to write fast wasm and fast Rust code. This, like code size, is much broader than Rust/WebAssembly itself (how to write fast Rust code is a much more general question) but there's a number of things we can probably easily mention:
opt-level = 's'
)I think we'd also want to link to general documentation about "making Rust code fast". I would prefer to avoid documenting "voodoo" like
codegen-units = 1
or similar, deferring that sort of advanced configuration to other documentation.The text was updated successfully, but these errors were encountered: