Why is GDB so slow on Windows?

[deisik]

Just to give you an idea how slow GDB is to show this in locals:

<Rebuild Watchmodel 17 @ 13:33:53.447 [347535ms] >
 Finished retrieving data.

It takes more than 5 minutes

What's wrong with it?

[JonB]

@deisik
Obviously it ought not take this long, but what do you have to show in locals? I assume it does not happen if e.g. you just look at an empty main() function.

[deisik]

Obviously it ought not take this long, but what do you have to show in locals? I assume it does not happen if e.g. you just look at an empty main() function.

Whatever. Even simple classes are taking like 20-30 seconds

The point is GDB is close to instant on Linux with the same codebase

I set _NO_DEBUG_HEAP = 1 and it didn't help

[JonB]

@deisik
I don't know. I don't use Windows gdb. Of course it's instantaneously fast under Linux.

Try obvious stuff:

• You're using command-line gdb in both, not a UI, right?
• You're not using/sitting in OneDrive, like I have seen some people do, are you?
• No "slow" devices for wherever it might be looking for source code, including system stuff, like, say, network/Internet?
• During the "5 minutes", run up Task Manager, is anything happening there? Is gdb using CPU time or not?
• Go into Resource Monitor. Look at the Disk activity. If it's doing anything check the file paths it's accessing.

[deisik]

Try obvious stuff:

• You're using command-line gdb in both, not a UI, right?
• You're not using/sitting in OneDrive, like I have seen some people do, are you?
• No "slow" devices for wherever it might be looking for source code, including system stuff, like, say, network/Internet?
• During the "5 minutes", run up Task Manager, is anything happening there? Is gdb using CPU time or not?
• Go into Resource Monitor. Look at the Disk activity. If it's doing anything check the file paths it's accessing.

I have 2 machines and it is absolutely the same on both of them. The application itself runs pretty fast so it is not a resource issue

It is all local, CPU is like 70% idle, no disk or network activity at all. GDB takes around 1Gb of memory, with 78% used all in all, so it's not memory related

[cristian-adam]

Not that it matters that much, but for protocol, which version of gdb are you using?

Do you have many breakpoints?

[deisik]

@cristian-adam

Mostly the one equipped with QtCreator. I tried whatever was installed before, no luck either. Today I installed QtCreator 11.0.0-rc1 (10.0.84), it didn't change anything

One breakpoint is enough to make GDB that slow

This issue seems to be with Windows, not so much GDB as such (I'm using Windows 10)

[cristian-adam]

Okay, I assume gdb 11.2.0 from c:\Qt\Tools\mingw1120_64\bin\gdb.exe.

gdb on Windows is known to be slow, and I don't think the developers are very keen on fixing stuff for Windows.

If I remember correctly gdb on Linux is using multi-threaded code, which is not enabled on Windows.

You could try either gdb on Linux with WSL2, or lldb.exe from https://github.com/mstorsjo/llvm-mingw.

[cristian-adam]

https://www.reddit.com/r/cpp/comments/u8awwt/faster_gdb_startup/ is the thread with the information about multi threading.

[deisik]

@cristian-adam
or lldb.exe

I tried that. lldb crashes on start-up

CALL: SETUP ENGINE
STARTING LLDB: 
ERROR: Lldb stderr: qtcreator_ctrlc_stub: Command line failed: ""

[deisik]

In fact, lldb wasn't in the path, so I corrected it and now lldb (Python?) complains:

ERROR: Lldb stderr: ValueError: compile(): unrecognised flags

[cristian-adam]

At https://bugreports.qt.io/browse/QTBUG-107516 I've posted two videos of Qt Creator 11 built with MinGW 11.2.0 and LLVM-MinGW 16.0.6.

• MinGW 11.2.0 - 1 min 14 seconds until this was expanded
• LLVM-MinGW 16.0.6 - 34 seconds until this was expanded

I had to compile Qt 6.4.3 mysef, I've uploaded my build here. It has debugging information and I think my path was c:/Projects/Qt/repo and I've compiled only the modules needed for Qt Creator.

[cristian-adam]

If all goes well at https://lists.qt-project.org/pipermail/development/2023-July/044172.html we could migrate to llvm-mingw and lldb!

gdb can't be slow anymore, when there is no more gdb 🙂

[deisik]

I switched to MSVC and now debugging is great again (with cdb)