Slow debugging using GDB with qt5 widget set

[c600g]

When debugging a shared linrary under Linux, I have to use GDB since fpDebug does not support library debugging currently. I've noticed that when Lazarus is compiled using the Gtk2 widget set, debugging performance is perfectly fine. However, when I build Lazarus with the qt5 widget set, the performance of the debugger when stepping through code becomes painfully slow.

Does anyone have any idea how I can improve the Lazarus qt5 debugging performance when using GDB?

[Martin_fr]

With Lazarus 2.3 you should be able to use fpdebug. (blue dots are missing in libraries, but that is visual only / well it affects the line mapping if you edit the code while debugging...)


I can't really see why QT vs gtk should make a difference.

What exactly slows down?

If it is loading your app?  That could be, if gdb tries to find symbols for qt libraries. And you can't skip symbols for libs, because you debug a lib....

I've noticed that when Lazarus is compiled using

Is your app always QT (or always gtk)? Independent of the IDE build?
Or could the speed depend on what your app is build with (rather than the IDE)?

[c600g]

I'm only running 2.2.6 currently, but I look forward to the 2.3 release and the ability to use fpDebug for libraries.

As for the slow down, it happens while stepping through code. When I pres 'F8' to step forward one line of code, I'm seeing a 1-5 second delay before the next line is highlighted. Makes stepping through the code extremely painful, as you might imagine.

The host app used to access the shared library is also written in Lazarus, but is compiled with the qt5 widget set by default.

Cheers

[Martin_fr]

There isn't really any good way to say if it is "gdb takes more time" or "something in the IDE".

You could check and compare the memory footprint of gdb for QT and for gtk.
More memory likely means more symbols loaded (that is, potentially symbols for QT). 

If it is QT debug info, I don't know where it is located, and maybe (if separate files) they can be moved, or otherwise it can be "strip"ed.


A couple of other things you can try...

1) Check if having the "view > ide internal > debug output" (not console, but "debug output") window open or closed has an impact.

2) Make sure your IDE is compiled WITHOUT heaptrc  (no -gh )  // though that affects gtk too

3) run your ide from a terminal => if there is any exception in the IDE you might see a stacktrace printed to the terminal => that can cause delays. And a trace would at least be a good starting point....

4) Ensure it is not time for evaluating watches/ locals.
=> Open "view > debug windows > debug history" => switch the "power button" to off.
=> close any debug window that you do not need (locals, watches, threads, stack) ) or "power button" them off.
-- this only has any effect if BOTH is done
-- this normally does not affect when the line after "stepping" is shown, as that should happen before the above does any diff.

5)

I'm seeing a 1-5 second delay before the next line is highlighted.

If it a 5 sec delay, then watching the gdb output should make it clear if the slowness is in gdb.

The output is
a) in the "debug output" - but that is IDE processed, and not 100% accurate
b) start ide from a console/terminal, and start with

Code: Text  [Select][+][-]

1. lazarus --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_ERRORS

This should have minimal impact by the IDE. I.e. the IDE prints that the very moment it reads it from the socket that is connected to gdb's stdout.
So unless QT somehow affects that socket....

You can see, at what time gdb prints

Code: Text  [Select][+][-]

1. TCmdLineDebugger.ReadLn "*stopped,reason="end-stepping-range",frame={addr="0x00000001000152e0",func="x",args=[]},thread-id="1",stopped-threads="all""
2.         << TCmdLineDebugger.ReadLn "(gdb) "

Anything up to that point is most likely in gdb. A different gdb version may or may not make a difference.

[c600g]

Martin,

Thank you very much for giving me a few things to chase down. I found that by disabling the "Debug Output" window that the qt5 widget set IDE now performs as well as the Gtk widget set IDE.

The repainting of the Debug Output window when using the Qt widget set must be an order of magnitude slower than the Gtk widget set.

Thanks again for the assistance!

[Martin_fr]

The "debug output" is a memo. The debugger is adding the internal communication to it. It's purpose is just for debugging the (gdb or lldb) debugger. (Hence it is in "Ide Internals"). You would not normally need it.

I assume that this then will affect any QT app adding text to a memo...

Anyway, good to know that the debugging now works for you.

[c600g]

Qt very well could support memos with variable line heights, as their list boxes can. There was a similar performance difference in an app I created between the Gtk2 and Qt5 widget sets due to many items being added to a list box (15,000+ regression test results) that was narrowed down to the same thing. Qt allows you to set some widget flags if all line heights are the same, which greatly increases the performance.

Cheers