wasm-micro-runtime
wasm-micro-runtime copied to clipboard
Enabling WAMR_BUILD_DEBUG_INTERP causes the program to run slower
I used the Windows environment to compile iwasm.exe for testing, and when the debugging feature is enabled during compilation, compared to no debugging feature the program runs very slowly.
After testing, it was found that it is because each opcode executes the macro HANDLE_OP_END, which performs a lock operation os_mutex_lock(&exec_env->wait_lock). Internally, it calls WaitForSingleObject, which executes very frequently, causing the program to run slower.
My build iwasm.exe method (using VS2022):
cd wasm-micro-runtime\product-mini\platforms\windows\build
cmake .. -DWAMR_BUILD_FAST_INTERP=0 -DWAMR_BUILD_DEBUG_INTERP=1
My test code wasm.c (never mind the div 0 exception)
#include <stdio.h>
static void foo() {
printf("foo=");
}
int main() {
int i = 1;
int j = (++i) + (++i);
for (int count = 0; ; count++) {
foo();
printf("%d----------%d\n", j, count);
if (count > 10) {
j = i / (j - j);
printf("%d----------%d\n", j, count);
}
for (int w = 0; w < 10; w++) {
printf("wait%d\n", w);
}
}
return 0;
}
My test method:
wasi-sdk-20.0\bin\clang.exe -g wasm.c -o wasm.out
iwasm.exe wasm.out
Unfortunately, I think this is necessary in order to support (wasm)instruction level step into/over.
It'd be nice if the WAMR engine could skip the extra mutex calls when the WASM binary lacks debug information.
I understand that debug builds are generally slower than release builds. However, I've noticed a significant slowdown in the classic interpreter, even without active debugging or debug symbols in my WASM binary. My current solution is to always use AOT and reserve the interpreter for debugging purposes only, ensuring there is no slowdown in my "release" WASM code.
I must note that I haven't actually looked at the source code for how WAMR executes the opcodes. This observation is based on OP's claim that with WAMR_BUILD_DEBUG_INTERP enabled, every opcode triggers os_mutex_lock(&exec_env->wait_lock). If this is causing the slowdowns I'm seeing, it would be nice if it were avoidable when debugging is not required.
@sohide we refined the code with #3704, could you please try again? Thanks.