If I write a little C program:
It’s super fast
~/slow 0.00s user 0.01s system 56% cpu 0.017 total
If I do pretty much the same thing in a juce gui program:
auto start = juce::Time::getCurrentTime();
auto end = juce::Time::getCurrentTime();
DBG((end - start).getDescription());
It’s slow af:
What could be going on? But if I do juce console app it’s on 16ms. It’s only slow when running under the debugger, so I guess I can deal with it, but it sure is annoying.
What juce modules are you linking? JUCE static lib is pretty big I guess and has many things loaded. Also all the extra threads being spawned takes time…
If there’s a release issue, you can profile it using instruments to get better insight.
Every system() call on MacOS gets brokered out to Apple’s servers to validate if a codesigned binary is being executed, or not.
Turn off your Internet completely and watch the difference in system() call times.
More details here, and yes this is a hassle:
That doesn’t explain why it’s different between a juce and non-juce app does it?
Might be more because of differences between how both projects handle notarization/codesign’ing during the build process. Are JUCE projects notarized by default?
I confess I haven’t drilled into this in full detail - so its just a theory that this is the issue the OP is encountering, but I’ve been bitten by this issue with system() calls recently also, which is why I thought to mention it …
I tried this in the GuiAppExample on an Intel and an M1 mac, both running macOS 13.1 with Xcode 14.2 (
lldb --version is
lldb-1400.0.38.17). On both machines, the
system call only takes around 10ms. Maybe the OS version, debugger version, and/or macOS SDK version are relevant.
Do you get different results with/without network connectivity?
My test app is here: juce_bugs/SystemTest/Source at master · FigBug/juce_bugs · GitHub
It happens on both my machines. Turning wifi off makes no difference. I see the issue with a juce gui app, but not a juce command line app or a pure c++ command line app. Look at the docs for system, it calls sh. Maybe sh is parsing dotfiles differently or something. No idea. Does this happen to anybody else but me?
M1 Ultra Mac Studio
Xcode Version 14.2 (14C18)
M1 MacBook Pro
Version 14.2 (14C18)
It takes 0.011s on my i9 in debug if that makes any difference (running at the start of Waveform launch as that’s what I had open at the time).
Similar story here, ~43ms on an i7 macbook pro.
What OS are you on @dave96? I’m on Montary 12.5.1, looks like @RolandMR is on Ventura so possibly it’s related to macOS version?
Ventura 13.0.1. On an older 2019 i9 MBP though.