Add a dedicated page about optimizing for speed

[alexcrichton]

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]

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]

Can I run criterion in a browser test?

https://github.com/bheisler/criterion.rs/issues/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]

thanks @fitzgen, that makes good sense.

and nice work in your fork there! :o