[ant5]

Unless you are eating 1,000 tic-tacs a minute, in which case they really start to add up.

We're talking about the potential to slow down every single function by inserting unnecessary register save/restores. The compiler is operating at a level where this sort of thing matters, and will make a difference in your code.

[alexgartrell]

If you're dominated by function calls, you're already wrong. Function calls are way expensive, because you're resetting like 4 registers and screwing over the instruction cache.

Give me a non-contrived example where this tiny amount of function call overhead makes an actual difference, and I'll eat my words.

[ant5]

If you're dominated by function calls, you're already wrong. Function calls are way expensive, because you're resetting like 4 registers and screwing over the instruction cache.

Give me a non-contrived example where this tiny amount of function call overhead makes an actual difference, and I'll eat my words.

A "non-contrived" example would require a whole-app benchmark; a micro-benchmark is already provided by the post author.

Nobody said the sky is falling (or that we're making a "mountain" out of it), but it is slower, and if it wasn't important to optimize function prologues/epilogues and register allocation, why exactly do we bother doing it at all?

To turn it around, give me a non-contrived example of a large code base where this "tiny" amount of function call overhead doesn't make an actual wall-clock difference, and I'll eat my words.

To put your complaint in context, you seem to be saying any micro-optimization of functional call overhead is not worth noting because it's noise amidst I/O, syscall overhead, or a million other things that are also expensive. A position which ignores the fact that the cheaper you make everything else, the more time you have left over for things you can't make cheaper.

[anamax]

> Function calls are way expensive, because you're resetting like 4 registers and screwing over the instruction cache.

Function calls don't screw over the instruction cache.

Executing code at lots of different addresses screws over the instruction cache.

[azim]

No, that's not really correct. The call itself in to the function and the return has the added cost of two extra instructions. But the trade off is that the function body itself now has an extra register to work with, so you should see an improvement in the execution speed of the function. The compiler is in fact operating at a level where this sort of thing matters, and in the real world function execution time will dominate call and return time.