Small function overhead

[Mechatrommer]

its sensible to split function like that to smaller meaningfull tasks from OOP, reusability or what not point of view. but as you've figured it out, it can deviates from your "performance and space" modus operandi. its easy to show the overhead difference for that smaller code, not that so for the real application. and truly speaking from what i understand, you cant measure "overhead" by judging from code size alone, it is how much cpu cycle that is going to be wasted doing housekeeping work and function call. and then you need to look at how many times the "overhead" will be called in your application life or at a single event. the "compromise" will depends on your specific situation, there is no telling if inlining is necessary at all time vs code readability. for smaller application, pretty much you can inline without seeing too much space penalty. discussion of "inlined" functions and "code space" are pretty much trivial for a software of a significant complexity, imho. "algorithm optimization" is far superior than this, something like if you can make N.N operation into N.log(N). you code "clean", the performance should follows. YMMV.

[Psi]

I would just make the functions as small as needed to make the code easy to read.

Performance is very rarely an issue with modern computers/micros, also the compiler is often much smarter than you.

Size-wise i guess there isn't much you can do but try it and see.

[Mechatrommer]

Size-wise i guess there isn't much you can do but try it and see.

performance'wise... nothing is much "fun" than setting up a timer code or looking at your stopwatch to look how long it will take for a led to blink

[andersm]

To give a little bit more context, here's the test functions I was using:

Have a look at the inlining section of GCC's manual. One thing immediately stands out: "calls that precede the function's definition cannot be integrated". Making the member functions private shouldn't make a difference, as a class implementation may be divided into several source files. Therefore when optimizing for size I'd expect that only function bodies cheaper than the function call would be inlined.

[andyturk]

I've been trying to work out if splitting a function into multiple functions, that only get called in the one place, has a performance penalty?

If you write something as a sequence of function calls, generally speaking, it's easiest for the compiler to translate those calls directly. So yes, you'll pay a little execution time for the function prolog/epilog, and perhaps a little extra code space to keep track of debugging info if you have that turned on, and don't forget about the stack space for pushing call-by-value arguments. Sounds bad, but does it matter?

Unless you've done an analysis of the overall program and have identified that particular sequence of calls as absorbing a huge amount of your CPU resource (e.g., 90%) it's almost pointless to even worry about performance vs coding style. Just write it the way it makes the most sense.

For blinking LEDs... why bother? But if your code is part of something whose complexity is polynomial or more (e.g., a sort routine), then you might gain something by tweaking the source.

"Make it right before you make it fast."

Implicit in that statement is that you have some measurements to guide the optimization effort.

[brainwash]

Size-wise i guess there isn't much you can do but try it and see.

performance'wise... nothing is much "fun" than setting up a timer code or looking at your stopwatch to look how long it will take for a led to blink

I know that at least MPLABX Simulator and CCS ICD have cycle-counting 'built-in'. In MPLABX if you set a breakpoint and 'resume' two times it will tell you the current cycle count at each break. In CCS you have to edit the breakpoint properties and modify something there. It's described in the basic tutorial.

Regarding overhead: unless it involves critical timing I would just forget about it and deal with it later where you can see if you must optimize for size or for speed. It's always easy to go back and inline the code yourself or just copy it than it is to split it later. Plus the added productivity that is in between.