Home/ Questions/Q 287889
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T05:45:59+00:00

I’ve finally managed to run the QtCreator debugger on Windows after struggling with the

  • 0

I’ve finally managed to run the QtCreator debugger on Windows after struggling with the Comodo Firewall incompatibilities.

I was hoping to switch from an older version of Qt and Visual C++ to the newest version of Qt and QtCreator, but the debugger performance is atrocious.

I have created a simple GUI with one window that does nothing else but display the window. After starting up QtCreator takes ~60MB RAM (Private bytes in Sysinternals process explorer).

When I start debugging, GDB is using 180MB. I start examining the main window pointer and it jumps to 313. Every time I try to inspect something, one of the cores jumps to 100% use and I have to wait for a few seconds for the information to show. This is just a toy program and I’m afraid that the real program that I want to switch will be much worse.

Is this kind of performance normal for MinGW? Would changing to the latest MinGW release improve things?

Visual C++ IDE + debugger + real-world program takes just close to 100MB of RAM and examining local variables is instantaneous.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Yesterday I built a copy of the Qt 4.5.2 libraries using MSVC 2008 and am using the QtCreator 1.2 MS CDB (Microsoft Console Debugger) support. It seems much faster than gdb. Building Qt for MSVC takes a few hours, but it might be worth trying.

    Also, that means smaller Qt DLLs and EXEs as the MS compiler/linker is much better at removing unused code. Some of the Qt DLLs are less than half the size of their MinGW equivalents. Rumour has it that the C++ code the MS compiler generates is faster too.

    • 0