GDB on QTCreator is super super fast. Almost instant.
On Lazarus it takes up to 5 seconds.
You are talking about:
1- the time it takes to start debugging (when you compile and run)
2- evaluation of watches
?
The goal of the integration of gdb, is to show the "best" values possible. GDB has a limited pascal understanding, and sometimes it needs help from the IDE. This means the IDE sends extra commands to GDB. Some of those are sent in advance. Eg, to test how the specific GDB on your system interacts with the specific app you have compiled by the specific version of fpc.
Some of that could be done in a more optimized fashion. But overall some of it cant be avoided. Or well it can, but then maybe a watch like MyDynArray[1].SomeRecord.Foo would return an error. (That is from memory, so maybe it was a similar expression... There are different pascal expressions that depending on the version of gdb/fpc may not work in gdb.)
IIRC There are even case where just access to class members (fields/var) would not work out of the box.
Most of this is lacking updates for newer versions, and maybe some of it could be faster with newer versions, but it is a huge job...
1) As for start up
One of the big chunks of time is setting up all environment vars.
But: If you do NOT "reset debugger after each run" then this is only the first time you start an app, or if you make changes to the env-vars.
Also the default installer comes with an older gdb. Newer gdb may be faster. You can get them on our sourceforge site (for win32/64).This is especially if your app has a lot of debug info. Like if you compile the IDE itself with debug info (over 100.000kb of debug info).
Therefore, if you do not need to debug lcl or packages, make sure to disable debug info for those. That can speed up both:
-linking (part of compile)
-start up time of gdb
2) watch eval
Not much that can be tuned.
However in Lazarus 2.0 some options were added. They help to prevent gdb to crash on out-of-mem. But they do add yet more time consumption....
To at least keep the current timing, on the Tools > Options > Debugger page, in the property grid: Find the two values with GDB....ValueMemLimit in the name, and set them all to equal values (eg 128000).
Do the same for the two Max....LenghtForStaticArray values.
In any case, if you are looking for speed, I do suggest to switch to Lazarus 2.0 (or currently the RC3, but some fixes are after RC3) and use FpDebug
Install the package LazDebuggerFp and set the debugger type (Tools > Options) to fpdebug. (the path to gdb will be empty / actually it is ignored)
LazDebuggerFp is a good deal faster. And at least on Windows it appears fairly stable (I use it a lot).
On Linux it is good, as long as your app is single threaded. (fixes for that will - once made - only go to trunk)
FpDebug is not yet feature complete. But all the main stuff (stepping, breakpoints, watches, locals, threads (on win)) are there.
Some examples of
missing things:
- watchpoints
- debug history
- support for some types in the debug inspector
- modify variables in the target
If FpDebug still crashes for you, then consider helping by reporting (reproducible) bugs.
Note that in 2.0rc3 it still has a good chance of crashing when you pause on a "begin" or "end" line (most outer begin/end of a function/procedure). This has been fixed (for all currently known cases) after RC3.
A final fix for that will require a bigger rework, and at some time be done in trunk.
btw, with fpdebug, you probably should use "reset after each run" (checkbox in options)
I don't mind adding a faster, basic gdb, that just returns the pure gdb results, with no extra work in the IDE.
But that would require someone else to write it.
I already have half a dozen debuggers in the IDE that take my time. So I really can't find the time to write yet another.