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;
}
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):
My test code wasm.c (never mind the div 0 exception)
My test method: