Why is GDB so slow on Windows?

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)