Inlining is also not a binary yes or no question. E.g. modern compilers can create clones of functions with constants propagated into some of the arguments, which gives some of the benefits of inlining. They are also free to change the calling convention (or make one up on the spot) for internal functions instead of inlining - something I'd like to see compilers explore further.

This is one area where modern JIT runtimes can dominate static compilations. Dynamic profile guided optimization adjusts things like inlining based upon how the live workload actually performs. You don't need to have any data ahead of time.

There are very few cases where I would trade this sort of long tail optimization capability for something like faster startup. Cold start happens once. If the machine rarely stops, it's not very relevant to the typical operational concerns.

Ultimately, there's too many factors to predetermine which approach is faster. Write clean code, and let a profiler guide optimizations when needed.

At first, write clean code with functions and don’t obsess over call overhead. Once it works, profile, then optimize where it actually matters.

Premature optimization, etc.