Author Topic: Small function overhead  (Read 10697 times)

0 Members and 1 Guest are viewing this topic.

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11518
  • Country: my
  • reassessing directives...
Re: Small function overhead
« Reply #25 on: February 18, 2013, 12:18:41 pm »
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.
« Last Edit: February 18, 2013, 12:40:17 pm by Mechatrommer »
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9875
  • Country: nz
Re: Small function overhead
« Reply #26 on: February 18, 2013, 12:37:45 pm »
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. :P

Size-wise i guess there isn't much you can do but try it and see.
Greek letter 'Psi' (not Pounds per Square Inch)
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 11518
  • Country: my
  • reassessing directives...
Re: Small function overhead
« Reply #27 on: February 18, 2013, 12:45:12 pm »
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 :D
Nature: Evolution and the Illusion of Randomness (Stephen L. Talbott): Its now indisputable that... organisms “expertise” contextualizes its genome, and its nonsense to say that these powers are under the control of the genome being contextualized - Barbara McClintock
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Small function overhead
« Reply #28 on: February 18, 2013, 02:06:04 pm »
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.

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
Re: Small function overhead
« Reply #29 on: February 20, 2013, 06:08:59 am »
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.
 

Offline brainwash

  • Frequent Contributor
  • **
  • Posts: 463
  • Country: de
    • Hack Correlation
Re: Small function overhead
« Reply #30 on: February 25, 2013, 10:49:32 pm »
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 :D

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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf