[oriolid]

So, I had to try this. And look what happened on a 2015 Macbook running Monterey (edit: but check the thread below for possible explanation):

  ojs@MacBook-Pro-4 /tmp % time ./a.out 
  Hello world
  ./a.out  0.00s user 0.00s system 1% cpu 0.268 total
  ojs@MacBook-Pro-4 /tmp % time ./a.out
  Hello world
  ./a.out  0.00s user 0.00s system 72% cpu 0.004 total

It's really that slow on first try. The binary was compiled just before running it, and it's the simplest possible hello world using C++ std::cout, compiled with -O3. C version with puts behaves just the same.

[alpaca128]

If applications were only slow the first time I wouldn't have any issue with it. But we all know that's not the case.

The difference you show depends on the internet connection, on slow wifi I've seen this delay go over 0.7s in the past. But again, just the first time, which is a problem for developers who recompile their code frequently but for the end user experience that's not as relevant.

[oriolid]

Do you know why running the binary is slow for the first time, and that it will be fast forever once it's been run once?

I thought it's common knowledge that starting apps for the first time after reboot or after doing something else is slower and usually it's explained by the app being in cache for the next launch. But here the it can't be cache, because reading anything from SSD can't be that slow and it should already be in cache anyway.

[alpaca128]

The first time you start a program on Mac OS it'll contact an Apple server to see if it's known malware or something like that. So it doesn't happen the first time after boot but the first time you ever run the program after installation or compilation.

[oriolid]

Thanks for the explanation. I thought code signing was supposed to reduce the need for this kind of checks. Still, stuff like this isn't helping with performance and if the new binary is sent somewhere outside the developer machine legal departments would be interested too.