Skip to content
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

Open
alexcrichton opened this issue Mar 1, 2019 · 3 comments
Open

Add a dedicated page about optimizing for speed #154

alexcrichton opened this issue Mar 1, 2019 · 3 comments

Comments

@alexcrichton
Copy link
Contributor

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:

  • Always measure. Rarely make changes unless performance differences can be measured, including all the suggestions we make.
  • Compile with LTO for maximum speed (and minimal size!)
  • If optimizing for speed, do not optimize for size (e.g. remove opt-level = 's')
  • Acknowledge that profiling within a wasm function isn't so hot today, but browser tools can provide good information about what wasm functions are hot

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.

@MaxBittker
Copy link

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 z to 3

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?

@fitzgen
Copy link
Member

fitzgen commented Mar 12, 2019

Can I run criterion in a browser test?

bheisler/criterion.rs#270

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?

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.

@MaxBittker
Copy link

thanks @fitzgen, that makes good sense.

and nice work in your fork there! :o

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants