wasmtime: Surprisingly slow module compilation
Thanks for opening a bug report! Please answer the questions below if they’re relevant and delete this text before submitting.
- What are the steps to reproduce the issue?
I have pushed a repository at https://github.com/wycats/wand/tree/str-wasmtime. The branch str-wasmtime is self-contained.
The script ./script/all.sh runs all of the build steps. The final step, ./script/run.sh, runs an executable, which is a Rust executable that uses the wasmtime embedding API. Its source is located in ./crates/wand-cli. The Rust source for the wasm is located in ./src.
The build scripts use wasm-pack to compile and optimize the wasm. They copy the .wasm file into a data directory in the wand-cli crate, which uses include_bytes! to get the bytes.
The executable has a bunch of println!s that list out the execution steps and how much time has elapsed.
- What do you expect to happen? What does actually happen? Does it panic, and if so, with which assertion?
I expect the Module::new step to be relatively fast. Instead, it takes several seconds on my machine.
- Which Wasmtime version / commit hash / branch are you using?
0.22.
- If relevant, can you include some extra information about your environment? (Rust version, operating system, architecture…)
$ rustc --version
rustc 1.52.0-nightly (d1206f950 2021-02-15)
$ cargo --version
cargo 1.51.0-nightly (ab64d1393 2021-02-10)
$ uname -a
Linux XPS-13-2019 4.19.84-microsoft-standard #1 SMP Wed Nov 13 11:44:37 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
I’m on Ubuntu 20.04 inside of WSL2 on Windows 10.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 21 (12 by maintainers)
Commits related to this issue
- log: compare `log` record `Level`s against the max level This branch adds a check against the current value of the max global `LevelFilter` hint in `tracing_log`'s `LogTracer::enabled` method. This s... — committed to tokio-rs/tracing by hawkw 3 years ago
- log: compare `log` record `Level`s against the max level (#1247) This branch adds a check against the current value of the max global `LevelFilter` hint in `tracing_log`'s `LogTracer::enabled` metho... — committed to tokio-rs/tracing by hawkw 3 years ago
- subscriber: set the max `log` `LevelFilter` in `init` (#1248) Depends on #1247. Since `tracing-subscriber`'s `init` and `try_init` functions set the global default collector, we can use the colle... — committed to tokio-rs/tracing by hawkw 3 years ago
- log: compare `log` record `Level`s against the max level (#1247) This branch adds a check against the current value of the max global `LevelFilter` hint in `tracing_log`'s `LogTracer::enabled` metho... — committed to tokio-rs/tracing by hawkw 3 years ago
- subscriber: set the max `log` `LevelFilter` in `init` (#1248) Depends on #1247. Since `tracing-subscriber`'s `init` and `try_init` functions set the global default subscriber, we can use the subscri... — committed to tokio-rs/tracing by hawkw 3 years ago
- log: compare `log` record `Level`s against the max level (#1247) This branch adds a check against the current value of the max global `LevelFilter` hint in `tracing_log`'s `LogTracer::enabled` metho... — committed to tokio-rs/tracing by hawkw 3 years ago
- subscriber: set the max `log` `LevelFilter` in `init` (#1248) Depends on #1247. Since `tracing-subscriber`'s `init` and `try_init` functions set the global default subscriber, we can use the subscri... — committed to tokio-rs/tracing by hawkw 3 years ago
- latest tracing-subscriber fixes performance problem reported in #2662 — committed to bytecodealliance/wasmtime by pchickey 3 years ago
- Merge pull request #2680 from bytecodealliance/pch/update_tracing_subscriber latest tracing-{subscriber,log} fixes performance problem reported in #2662 — committed to bytecodealliance/wasmtime by cfallin 3 years ago
@softprops Checking out the latest softprops/fasttime@94faa0e7bd351b67e8d1444e0bc09c32764111b2 on macOS I get the same timings as @lqd got above (using the same app as well). Loading the module you referenced above it says it compiles in ~90ms.
To confirm, are you sure that you’re building fasttime with
--release? 60ms to 6s sounds like a Rust release mode thing that would cause the slowdown. Otherwise do you perhaps have any environment variables configured likedRUST_LOGor similar?That article mentions parallel compilation as reason that it is faster. This is already the default with Wasmtime.