Debugging ESP32 project with multiple threads can be very slow

[drorgl]

For example a project with 20 threads, totaling 26 threads (main, IDLE, IDLE, ipc0, ipc1, esp_timer) can take 6-8 seconds to step.

I've analyzed the problem and it seems its in this package or in platformio-vscode-debug, while the source code was not available it does seem similar to Enneary/module-debug.

Digging in the requests that cause the slow down in GDB, it seems that even when the REGISTERS and CALL STACK debugger panes are collapsed, the plugin still requests the underlying register-values and threads.

The threads or info threads is very slow in ESP32/GDB and takes most of the time between step / next.

It would seem like an easy fix to speed things up for someone who understands how VSCode debugger extension works: check if the pane is open and if not, don't request the data needed to update it.

Attempting to increase the debug_speed didn't help.

While you're at it, add a check for PERIPHERALS pane as well.

[ivankravets]

Could you try to collapse "Registers" + "Peripheral" views and restart VScode? It should work.

P.S: We plan soon to rewrite from scratch debugging component with a lot of new features and improvements. Sorry for the current issues.

[james-h-dt]

Collapsing "Registers" and "Peripheral" view + restar VSC did not improve debug speed for me. Also tried collapsing all views in the debug panel (except the essentials: Breakpoints and Watch). Same behaviour seen. I was using a very simple single-threaded test app. Each debug step took 3 - 5 seconds.

[dotnfc]

the same. i use wsl2 + vscode + s3 build-in jtag to debug idf hello-world project, a single step can be 1~2 seconds ( with 'set ESP_RTOS none' )

[YutingYou]

Same for me, using esp32s3 build-in jtag on macOS

vscode + espidf debug: step debug is very slow, 1~2 seconds vscode + cppdbg: normal speed terminal + openocd +esp-gdb: normal speed

Any thought?

[SnazzyBlanket]

any update on this? extremely slow for me as well.