Slow app start on M5 MacBook Air / Tahoe 26.5.2

[pleumann]

Hello,

I noticed that starting an app with Lazarus 4.8 on recent Mac HW/SW has become considerably slower than it used to be. It takes 5-10 seconds to start an app, even one with basically an empty form. It seems to be the debugger. Explicitly starting without the debugger is more or less immediate. Is there anything I can do about that by changing my config?

Best regards
Joerg

[Martin_fr]

I don't have a Mac for testing myself. But a few "maybe" pointers...

"The debugger" => On Mac consist of 2 parts: LLDB and FpDebug.

For starters I don't know if there is anything affecting LLDB, such as maybe if x86 code needs to be run in emulation... I don't know your setup. Or if that is even still possible, or if only M-CPU code will run.


The only other thing that I can think of, is the amount of debug info. You can check if packages and LCL are compiled with debug info, and if you don't need that, then change it (probably remove from "configure build Lazarus", but maybe other places).

You can check if it is lldb, by trying "LLDB alpha" without FpDebug (it be crappy debugging, but it shows the speed part of LLDB). Or even try LLDB from command line.

If it is FpDebug, then the question is what changed since 4.6 ?? May I assume it worked faster in 4.6? Are the exe-bundles of the same size? I.e. is the amount of debug info roughly the same?


Also you could try running Lazarus from a console/terminal. So you get to see its STDOUT/STDERR. Maybe it prints some error messages that provide more info.

[pleumann]

First of all, thanks for the suggestions!

lldb without FPDebug takes just as long as with.

Running from the command line doesn't provide additional info. Compilation is quite fast, a second or so. The time is being spent after this

Code: Bash  [Select][+][-]

1. Info: (lazarus) [TCompiler.Compile] end
2. Hint: (lazarus) [TMainIDE.DoBuildProject] compiler time in s: 0,933000119403005
3. Info: (lazarus) [TMainIDE.DoBuildProject] Success
4. Hint: (lazarus) [TMainIDE.DoRunProjectWithDebug] Debugger=TFpLldbDebugger
5. Hint: (lazarus) [TMainIDE.DoRunProjectWithDebug] END

and there is no output from/regarding the debugger.

It will be a bit tricky to compare to my older setup. I'm not sure I ever ran 4.6 on this Mac and this MacOS regularly. It's possible this was a system that still had gdb. Or even an older Intel iMac I've been using until recently (and that, quite likely, used gdb).

Where would I find this option to restrict the debugging information?

[Zvoni]

Mac's Gatekeeper interfering?
https://help.apple.com/xcode/mac/current/en.lproj/dev9b7736b0e.html

[pleumann]

Mac's Gatekeeper interfering?
https://help.apple.com/xcode/mac/current/en.lproj/dev9b7736b0e.html

I disabled this for a brief test, but there's no difference. And the startup without debugger is almost immediate, so I think it's most likely lldb.

[Zvoni]

Mac's Gatekeeper interfering?
https://help.apple.com/xcode/mac/current/en.lproj/dev9b7736b0e.html

I disabled this for a brief test, but there's no difference. And the startup without debugger is almost immediate, so I think it's most likely lldb.

hmm.....are you using this "Debugger-from-server" or whatever it's calledß
Or is LLDB itself configure to access some server-thingy?
I seem to remember such an option

[Martin_fr]

Well try to disable debug info for all else....

Just enable "strip" in the Project options (I hope the IDE wont complain..../not tested). You wont actually be able to debug, and breakpoint will not work. But you can see how much impact it has on the startup

Debug info is huge. Massive. And loading it takes some time. Though it shouldn't take as much as it does for you.

If I debug the IDE (which is really big) then loading debug info can take 3 to 5 seconds. But then I don't think your app has such much debug info...

-----------------
Definitely try a clean build.

Remove your old bundle and create it from scratch.
Also if there is a 2nd folder with the base name of your app (not sure the exact extension, something related to dbg) for debug info, then remove that too.

Or maybe easier, copy your sources into a new folder, and build there. No old baggage that could interfere.

[Zvoni]

Well try to disable debug info for all else....

Just enable "strip" in the Project options (I hope the IDE wont complain..../not tested). You wont actually be able to debug, and breakpoint will not work. But you can see how much impact it has on the startup

Debug info is huge. Massive. And loading it takes some time. Though it shouldn't take as much as it does for you.

If I debug the IDE (which is really big) then loading debug info can take 3 to 5 seconds. But then I don't think your app has such much debug info...

-----------------
Definitely try a clean build.

Remove your old bundle and create it from scratch.
Also if there is a 2nd folder with the base name of your app (not sure the exact extension, something related to dbg) for debug info, then remove that too.

Or maybe easier, copy your sources into a new folder, and build there. No old baggage that could interfere.

i read something about LLDB indexing the Symbol-Table.
Maybe something to look into?
As far as i could understand it, it didn't have anything to do which Language/IDE the user was using, but that the slowdown was 100% LLDB's issue

[Thaddy]

I am trying to replicate on my Mac (M4 mini, bought for just such issues): initial experiments tells me you are right.
Now I have to find the cause......Which seems not trivial. Any help is appreciated because I am stuck at the moment.

Plz don't comment if you can not test on Apple hardware.

[Martin_fr]

Well, if LLDB got updated....

Indexing at startup could certainly have some impact.

I found the following 2 links.
https://discourse.llvm.org/t/lldb-startup-takes-15-seconds-parsing-symbol-tables/65487
https://lldb.llvm.org/use/ondemand.html

I don't know if there is a way to set those via some config file.

If you can confirm that this is the cause, then I can see if it can be added to the IDE. Though, I have to see if I can test it on my Linux lldb, so it wont break debugging with older versions.

[Thaddy]

https://discourse.llvm.org/t/lldb-startup-takes-15-seconds-parsing-symbol-tables/65487
https://lldb.llvm.org/use/ondemand.html

The first link is VERY helpful. I have to examine the reach of the second link, though.

Thanks, Martin

(btw i can confirm that when started stand-alone the executable is instant)

[Martin_fr]

If you want to play with it in the IDE

In  components\lazdebuggers\lazdebuggerlldb\lldbdebugger.pas
find

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

1. procedure TLldbDebuggerCommandInit.DoExecute;

It has a lot of "Instr := ... QueueInstruction(...)"

Add at the start of it (either this setting, or any of the other proposed settings)

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

1.   Instr := TLldbInstructionSettingSet.Create('symbols.load-on-demand',  'true');
2.   QueueInstruction(Instr);
3.   Instr.ReleaseReference;
4.  

If that helps, please also try what happens if you intentionally misspell the setting
Instr := TLldbInstructionSettingSet.Create('symbols.foobarunknown', 'true');
or
Instr := TLldbInstructionSettingSet.Create('foobarunknown.abc', 'true');

Because that is what it looks like for older lldb.

[Martin_fr]

And please report the exact version of your lldb.

[Thaddy]

I was just posting that, so I won't...
Anyway my machine is up to date, so it happens regardless. That is the frustrating part.
I will follow your instructions and report back.
What I also need to know if you compile for Intel or native AARCH64. Note it will run both Intel64 and AARCH64, but Apples AARCH64 have a penalty for Intel code, because it invokes an emulation layer.
Freepascal supports both! I am testing with AARCH64 native, not Intel64.
I can not test Intel Macs anymore: that one died and 2020 was the cross-over.

I just stop for now. Interesting problem.

[pleumann]

And please report the exact version of your lldb.

joerg@Air-M5-von-Jorg lazarus % lldb -version
lldb-2100.0.17.203
Apple Swift version 6.3.3 (swiftlang-6.3.3.1.3 clang-2100.1.1.101)

Trying your suggested changes now...