Emscripten Debugging in Chrome Dev Tool is loading a lot of emscripten files which is make the debugging very slow

[aharondavid]

Debugging with -g cause to loading a lot of Emscripten files in the Chrome Dev Tool which might cause to debugging to be very slow.
Is there a way to ignore them ?

[sbc100]

@pfaffe do you know what this means? Is it a problem?

[pfaffe]

Large numbers of sources are not generally a problem in and of itself, but if the debug info is huge that can slow things down.
We wrote down some guidance for how to deal with large applications here: https://developer.chrome.com/blog/faster-wasm-debugging

Can you clarify what precisely is becoming slow?

[aharondavid]

Hi @pfaffe

I've taken note of the guidance provided above. Before delving further, let me provide some essential details about my application:

The application is statically built using Emscripten, resulting in a single large WASM file named TerraExplorerApp.Emscripten.wasm. Additionally, it's configured to utilize 60 worker threads.

In terms of file size:

Debug mode:
TerraExplorerApp.Emscripten.wasm: 176MB
TerraExplorerApp.Emscripten.wasm.dwp: 75MB

Release mode:
TerraExplorerApp.Emscripten.wasm: 35MB

Regarding the debugging issues:

1. Loading the app with debug information significantly increases load times compared to loading without debug information.
2. The presence of multiple breakpoints in certain C++ files exacerbates debugging performance.
3. Chrome Dev Tools frequently crashes.
4. Refreshing the page takes a substantial amount of time. In such cases, I prefer to terminate the tab and open a new one.
5. Occasionally, the Dev Tools get stuck while loading the WASM file. It's unclear what specific conditions trigger this behavior and cause the file to remain in a loading state.

The app debugging is conducted at http://localhost:6931/ (Server created by Emscripten emrun.py). None of the aforementioned problems occur when working on a real server, but C++ debugging outside of http://localhost/ isn't feasible.

Here's a link to the App Debug: App Debug Link

[pfaffe]

To improve load times you can try building with -gseparate-dwarf. This causes emscripten to emit two modules, one without symbols to be loaded by the page, and another with symbols to be loaded by devtools.

In what way does devtools crash exactly?

[aharondavid]

It seems that the loading is faster with -gseparate-dwarf .
The crash is arbitrary - DevTools is stuck or it just closed

[pfaffe]

Do the crashes occur in any specific situation? I see for example you're opening the wasm module itself in the screenshot above, which would consume quite a bit of memory.

It's hard to guess what's going on. Do you have a way we could reproduce the problems?

[aharondavid]

sometimes, opening the wasm module is done automatically by the DevTool when I try to do - Debug Step In in some c++ file.
not clear to me the rule that cause to open the wasm file by debugger.