3 ms·

Do you think that's a good practice? I have always been conflicted. For one, writing a new function isn't just for vanity--it changes the actual machine code g

by Gunax 7y ago

Do you think that's a good practice? I have always been conflicted. 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. But sometimes it just is easier to move a bunch of crap to a function and abstract it away.

vivekseth 7y ago
I’d bet that the compilers mostly commonly used would probably inline a function only used once. If not, many languages provide an `inline` keyword to tell the compiler to in-line the function directly. Even if there was no way to inline a function, I tend to prefer code that is easy to understand over code that manages to shave off a few extra instructions. Code that is hard to understand will be hard to maintain and can lead to bugs in the future.
usr1106 7y ago
> 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.

by Gunax 7y ago

vivekseth 7y ago

I’d bet that the compilers mostly commonly used would probably inline a function only used once. If not, many languages provide an `inline` keyword to tell the compiler to in-line the function directly. Even if there was no way to inline a function, I tend to prefer code that is easy to understand over code that manages to shave off a few extra instructions. Code that is hard to understand will be hard to maintain and can lead to bugs in the future.

usr1106 7y ago

> 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.