Time Profiling

    The performance.now() function returns a monotonic timestampmeasured in milliseconds since the Web page was loaded.

    Calling performance.now has little overhead, so we can create simple, granularmeasurements from it without distorting the performance of the rest of thesystem and inflicting bias upon our measurements.

    We can use it to time various operations, and we can accesswindow.performance.now() via :

    All Web browsers' built-in developer tools include a profiler. These profilersdisplay which functions are taking the most time with the usual kinds ofvisualizations like call trees and flame graphs.

    Note that these profilers won't show inlined functions, and since Rust andLLVM rely on inlining so heavily, the results might still end up a bitperplexing.

    Resources

    allow you tolog the timing of named operations to the browser's developer tools console. Youcall console.time("some operation") when the operation begins, and callconsole.timeEnd("some operation") when it finishes. The string label namingthe operation is optional.

    You can use these functions directly via the web-sys crate:

    Here is a screenshot of logs in the browser's console:

    Additionally, console.time and console.timeEnd logs will show up in yourbrowser's profiler's "timeline" or "waterfall" view:

    The same way we can often leverage our operating system's native code debuggingtools by writing #[test]s rather than debugging on the Web, we can leverageour operating system's native code profiling tools by writing #[bench]functions.

    Write your benchmarks in the benches subdirectory of your crate. Make surethat your crate-type includes "rlib" or else the bench binaries won't beable to link your main lib.

    However! Make sure that you know the bottleneck is in the WebAssembly beforeinvesting much energy in native code profiling! Use your browser's profiler toconfirm this, or else you risk wasting your time optimizing code that isn't hot.

    Resources