Are there still obvious optimizations/improvements to be done with the "LLDB with fpdebug" debugger on macOS? We're on trunk and it's largely not usable right now. I'm sure it has something to do with the size of our project, but it currently has random, lengthy hangs when doing things like single stepping. If I wait long enough it does eventually come back, but it is very much in the range of "Is this hung?" and not just sluggish. It adds 10+ seconds to actually launching the app too, which is unpleasant, but at least something I can expect and work around.

It all depends on usable bug/issue reports.

There are steps on how to generate a logfile.
http://forum.lazarus-ide.org/index.php/topic,42869.0.html

Startup is known to take some time. Both the IDE, and lldb need to parse the debug info, and both take some time to do so. (both running in parallel threads for this).
To speed up, make sure that you disable debug info for any package, you do not need to step into.

In case of hangs while stepping, it would be useful to know the start/endpoint (file/line). So it can be found in the log.

It may be the debugger is evaluating locals, watches or stack, and that any of them have large objects.
1) Do you have locals/watches windows open? Are there any variables that may have a bigger size? Or objects with plenty of strings?
2) Try to
 - close the locals window
 - close or disable the watches window
 - open the history window, and disable it (this is important, for else it will go and start reading locals and watches)

When you press step, the debugger will (should?) abort reading locals and watches. But it will only do so between 2 watches. If a single watch takes a lot of time, this may add delays.

--------------------
If it is for speed only, you can try the lldb without fpdebug (there is a package under components/lazdebuggers/lazdebuggerlldb  ; with NO "fp" in it)
This package comes "as is".
All watches expect lldb readable (c-style) input: form1->fvalue And results are displayed as llbd likes.

But for an object with lots of strings, lldb gets the entire value. THe IDE only needs to do a single request.
FpDebug, needs to first read the mem of the object, and because strings are pointer, it then needs a further request to lldb for each string.

Just an update

I made some changes to trunk. As a side-effect the debugger may start a bit faster. But I would expect it to be a very small improvement, if any at all.

http://forum.lazarus-ide.org/index.php/topic,44561.msg313527.html#msg313527 You may get a warning at start, in certain cases. See the forum post. The warning can be disabled in the ide menu: Tools > Options under debugger.

In case of hangs while stepping,

...

When you press step, the debugger will (should?) abort reading locals and watches. But it will only do so between 2 watches. If a single watch takes a lot of time, this may add delays.

To clarify:
The "hangs" during single stepping. Which of the 2 describes the issue:

1) When the debugger is paused (from after the last step), and you press F7/F8 the debugger does not react immediately.
The app remains paused (the green arrow in the gutter, is still visible), and only after some time, the step is started (the green arrow disappears, and then re-appears on the next line)

2) The step starts immediately (the green arrow disappears). But it takes a long time until the app stops at the next line. (and the line you step over, is not calling some time consuming function / the line is not a single line loop, that will loop for a long time)

For 1:
It appears I was wrong. Watch/Locals evaluation is not currently interrupted. So this may cause long delays.
I will be looking into this.

For 2:
Not sure.
If you step over a function, and there are exceptions raised (and to be ignored by the debugger) then it takes the IDE some extra work to get back to the calling function.
But this should not take than long.

I looked into it. Fixed in trunk.

Please let me know if this improves the situation.

Martin,
Thank you for both the suggestions and looking into it. I'm on something else right now, but I'll give everything a try in the new few days and let you know how it goes.

Martin,

Thank you for looking into it. I've been testing the latest version over the past couple of weeks and it seems to be working well. I'll keep an eye on it and let you know if I see any more unexpected hangs.

Zoë