Slow app start on M5 MacBook Air / Tahoe 26.5.2

[pleumann]

If you want to play with it in the IDE

In  components\lazdebuggers\lazdebuggerlldb\lldbdebugger.pas
find

Code: Pascal  [Select][+][-]

1. procedure TLldbDebuggerCommandInit.DoExecute;

...
[/code]

I did that. Interestingly, it raised the startup time from 10 seconds to more than 15 seconds. I then reverted the change (back to 10 seconds) and added the one line to ~/. lldbinit, as suggested in one of the two linked articles (15+ seconds again).

My generated binaries are Arm64. I validated that. Starting without debugger is instant. If there's anything else I can do or check to help, please let me know.

The discussion behind one of the links suggests keeping lldb running and only connecting to it for each executable to be debugged. Not sure if that's an option. It would probably be a bigger change to Lazarus' internal way of handling debugging.

[Martin_fr]

Strange... The timings.

But I can't currently test myself. I have lldb under Linux, but they are all older and don't have the issue (I need to setup a new VM, and get an uptodate lldb, and hope it exposes the issue....

You can check in menu: View > Ide Internals > Debug output
In which order commands are sent to lldb.
But I was sure the command would have been sent first.

Maybe it is needed global (the call takes a boolean flag for that).

Maybe it is indexing something else before...

Can the setting be given on the command line?

You can try

Code: Pascal  [Select][+][-]

1. procedure TLldbDebugger.Init;
2. var
3.   Cmd: TLldbDebuggerCommandInit;
4. begin
5.   FDebugProcess.CreateDebugProcess('', Environment);
6. ...

Replace the empty string (first param) with whatever would be the setting.

Problem here, the IDE would not know what lldb version it is launching => so it can't conditionally apply this.
Then it might break older lldb.


As for "keeping lldb running". You can try to change

Code: Pascal  [Select][+][-]

1. function TLldbDebugger.NeedReset: Boolean;
2. begin
3.   Result := true;
4. end;
5.  

to false. IIRC then it should (hopefully) keep it running. Not sure how well that will work. (It must have been a problem back when I added it)

Mind, that the article may be talking about lldb-dab (an lldb server like....) While the IDE just uses the command line lldb.

[pleumann]

As for "keeping lldb running". You can try to change

Code: Pascal  [Select][+][-]

1. function TLldbDebugger.NeedReset: Boolean;
2. begin
3.   Result := true;
4. end;
5.  

to false. IIRC then it should (hopefully) keep it running. Not sure how well that will work. (It must have been a problem back when I added it)

Changing that to False means the debugger will hang on every debugging attempt after the first one. That may be the reason you introduced it.

[Martin_fr]

Changing that to False means the debugger will hang on every debugging attempt after the first one. That may be the reason you introduced it.

It might need some clean up that isn't done (like maybe the opposite of "create target"...)

But then again, the command line "lldb" normally is used from console (by a human) to debug once, and then quit. Back then I didn't know about lldb server (or lldb-dab or whatever there apparently is / heart of it recently but haven't investigated)

[Thaddy]

Just my two cents, I am still stuck, though:
- debugging works but is noticeably slower than before (confirmed). Functionality is correct.
- the code is not emulated intel, but true AARCH64
- it is a M5 machine, not an M4 like mine: there is a slight chance that makes a difference.
- compiled code outside debugger runs at normal speed. No delays.

I can't find any obvious flaws and debugging is always slower anyway.
Timing issues should be debugged differently anyway.
I would close it. Was a long night. I did my best.
I think the cause is lldb, not our side, since it exposes a (the same?) delay too.
Can you test that? The new, longer, delay also happens on Raspberry Pi's 4 and 5 -. I checked that.
So it is not an Apple only issue.

[pleumann]

Just my two cents, I am still stuck, though:
- debugging works but is noticeably slower than before (confirmed). Functionality is correct.
- the code is not emulated intel, but true AARCH64
- it is a M5 machine, not an M4 like mine: there is a slight chance that makes a difference.
- compiled code outside debugger runs at normal speed. No delays.

I can't find any obvious flaws and debugging is always slower anyway.
Timing issues should be debugged differently anyway.
I would close it. Was a long night. I did my best.
I think the cause is lldb, not our side, since it exposes a (the same?) delay too.
Can you test that? The new, longer, delay also happens on Raspberry Pi's 4 and 5 -. I checked that.
So it is not an Apple only issue.

I don't see it on Raspberry Pi 5, and I develop on a Pi 500+ a lot these days, actually more than I do on Mac. Debugging is instant there. No difference to starting without debugger. Maybe I need to check which backend I use. I can do that tomorrow (machine is at the office), but it's most likely gdb. I tried switching to gdb on Mac, too, btw. But the MacPorts recipe seems to be broken. I cannot install it cleanly.

We also noticed the problem on another Mac at work. It's not an M5, but an M3 or M4. I can validate that, too.

Thanks a lot for looking into this! As I wrote, if there's anything I can do to assist, let me know.

[Thaddy]

If you use gdb/mi which version? I used lldb on the RPi's too, because you specified that.

[pleumann]

If you use gdb/mi which version? I used lldb on the RPi's too, because you specified that.

I wasn't aware lldb is a thing on Raspberry Pi OS. I think my installation defaults to gdb. I will provide the details on Monday (I wrote tomorrow at first, but I really meant Monday).

[Thaddy]

Yes the default is GDB/MI on Raspberry Pi. But I use clang and Go a lot and that is llvm, so I have lldb on my Pies.
I am almost sure it is lldb that causes the issue, but it is not really important because debugging works.

[pleumann]

Yes the default is GDB/MI on Raspberry Pi. But I use clang and Go a lot and that is llvm, so I have lldb on my Pies.
I am almost sure it is lldb that causes the issue, but it is not really important because debugging works.

I had a chance to check, and debugging via lldb-fpdebug on Rpi5/Trixie is immediate. There is no noticeable delay (and the CPU is much, much slower than Apple's M5).

[Thaddy]

Then it must be something we have to investigate further. Not happy with that.
Note my M4 <> your M5 and that can still make a difference in our results. (apart from speed)

[pleumann]

Then it must be something we have to investigate further. Not happy with that.
Note my M4 <> your M5 and that can still make a difference in our results. (apart from speed)

I just checked: The other machine in our team where we noticed the delay is an M4, most recent OS.

It sounds to me like lldb is the culprit, maybe even just the Apple version of it. I think I stumbled upon other (non-Pascal) reports that startup is very slow or has become slow.

[Thaddy]

@pleumann

Let's keep it open at the moment, though: even if it is lldb, which I suspect, we need to know the cause, but for me I have higher priorities. It should not disappear.
It may be even solved in a next OS or xcode update, because I saw those other complaints too...

If you have crashes, then it is a different story, but: debugging works, priority drops.

Feedback from other M series Apple users is highly appreciated.

[pleumann]

Fine my me. I do most of my current work on Pi5 where it's ok.

On MacOS I can simply work around it by starting without debugger.

But for new users (who are not aware that starting via debugger is the default) it might leave a strange impression that starting a Lazarus App takes 15 seconds.

[Thaddy]

@pleumann
Yes. But we determined that that is not the fault of Lazarus. Keep it open and wait for more participants.

@Martin_fr
There is no immediate problem with debugging, because that works and others outside of the Lazarus/FPC community experience the same thing. It is a tooling issue and there will likely be an update.
We had a thorough look.