> For one, writing a new function isn't just for vanity--it changes the actual machine code generated (unless an optimizer is smart enough to fix it). I don't like changing the actual operation just to make a program more readable.
Inlining should, but does not always prevent this. Because compilers have all kind of limitations when they are no longer able to inline. From what I read I have got the feeling it got better in recent years, but I have not studied the issue.
That said for > 99% of the code written a function call has no measurable performance impact. Few of us write code in a hotspot of an operating system or a very tight loop of some number crunching application. A bit more than 1% might possibly write vectorized code, but still the huge majority never does.
Programming suffers much more from bugs than performance issues. And if there are performance issues, they are typically because of improper algorithms, wrong I/O patterns or high memory consumption, not because of a couple of additional function calls.
Inlining should, but does not always prevent this. Because compilers have all kind of limitations when they are no longer able to inline. From what I read I have got the feeling it got better in recent years, but I have not studied the issue.
That said for > 99% of the code written a function call has no measurable performance impact. Few of us write code in a hotspot of an operating system or a very tight loop of some number crunching application. A bit more than 1% might possibly write vectorized code, but still the huge majority never does.
Programming suffers much more from bugs than performance issues. And if there are performance issues, they are typically because of improper algorithms, wrong I/O patterns or high memory consumption, not because of a couple of additional function calls.