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
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
TCmdLineDebugger.ReadLn "*stopped,reason="end-stepping-range",frame={addr="0x00000001000152e0",func="x",args=[]},thread-id="1",stopped-threads="all""
<< TCmdLineDebugger.ReadLn "(gdb) "
Anything up to that point is most likely in gdb. A different gdb version may or may not make a difference.