[Performance] 'Memory.grow' instruction has resulted in a significant extension of the execution time
Describe the bug
Hello, I caught the following performance anomalies while using Wasmer. The specific performance is as follows:
The data is in seconds, and each data is the result of ten executions and averages.
Environment
The runtime tools are all built on release and use JIT mode.Wasmer uses the Cranelift backend, and the execution time of the llvm backend for this test case is basically the same as that of Cranelift.
- wasmer:wasmer 6.0.1
- wasmtime:wasmtime 35.0.0 (9c2e6f17c 2025-06-17)
- wasmedge:version 0.14.1
- WAMR:iwasm 2.4.0
- wabt:1.0.27
- llvm:18.1.8
- Host OS:Ubuntu 22.04.5 LTS x64
- CPU:12th Gen Intel® Core™ i7-12700 × 20
- rustc:rustc 1.87.0 (17067e9ac 2025-05-09)
binary: rustc
commit-hash: 17067e9ac6d7ecb70e50f92c1944e545188d2359
commit-date: 2025-05-09
host: x86_64-unknown-linux-gnu
release: 1.87.0
LLVM version: 20.1.1
Steps to reproduce
# wasm2wat or wat2wasm
wasm2wat -f test_case.wasm -o test_case.wat
wat2wasm test_case.wat -o test_case.wasm
# Execute the wasm file and collect data
perf stat -r 10 -e 'task-clock' /path/to/wasmer run test_case.wasm
perf stat -r 10 -e 'task-clock' /path/to/wasmtime test_case.wasm
perf stat -r 10 -e 'task-clock' /path/to/wasmedge --enable-jit test_case.wasm
perf stat -r 10 -e 'task-clock' /path/to/build_fast_jit/iwasm test_case.wasm
perf stat -r 10 -e 'task-clock' /path/to/build_llvm_jit/iwasm test_case.wasmExpected and actual behavior
test_case.wasm causes large execution time differences between several runtimes, with wasmtime and wasmer being particularly pronounced. The execution time of wasmer is about 5x-6x, and the execution time of wasmtime is about 7x-9x.
I did an analysis of tase_case.wat and found that when I deleted the code like the following for 50-52 lines, the execution time is as shown in modified.wasm. At this point, the results of each runtime are relatively normal. From this I think the following directives may be causing performance anomalies in both runtime tools.
(drop
(memory.grow
(i32.const 1)))Additional context
I also submitted an issue about the phenomenon to wasmtime.
If you need any other relevant information, please let me know and I will do my best to provide it. Looking forward to your reply! Thank you!
Source: wasmerio/wasmer