Performance Benchmarking Tips

[stevekrouse]

We should create a page in the docs to collect tips for benchmarking performance:

1. Start by measuring your JS, and confirming that it's slow in a way that Rust/Wasm will be faster in (with rough estimates of how much faster, and a link to a benchmark):

parsing - yes (2.5x faster)
matrix math - yes
generating vertex shaders - yes
dom manipulation - no

When in doubt, ask the Slack if the slowness in your app can be improved by Zaplib before you invest time into writing a port!

3. Use performance.now in JS & Instant::now() in Rust
4. Run the tests a couple of times and take an average
5. Run the wasm tests with the browser devtools closed (open after or use HTML to see results)

[pankdm]

I think Instant::now() won't work in Rust when compiled into wasm. Probably better use zaplib::UniversalInstant::now() instead?

[stevekrouse]

Oh damn! That's what I was using... What's the problem with it?

[janpaul123]

Hm it seems like it infers to use UniversalInstant from this: https://github.com/Zaplib/zaplib/pull/166/files#diff-6ab2609914bb3aa54a94aa7d90dc83537e41efed475d85ddbb31ed3e413f5aadR44 I guess since we define and implement an Instant trait for UniversalInstant. We probably shouldn't do that to avoid confusion with std::time::Instant..

[pankdm]

Ah, yes! That's quite confusing usage. I suspect if you remove type annotation of UniversalInstant then it won't compile/work anymore - so you are indeed using UniverstalInstant not the typical std::time::Instant.

[stevekrouse]

Oh fascinating! It did error and suggested I add that type annotation, so that's how the code ended up in that state.

[stevekrouse]

Maybe we link to resources like this https://nnethercote.github.io/perf-book/introduction.html