[Courses] C Programming For Absolute Beginners, Lesson 5A: All About Functions, Part 2

[Jacinta Richardson]

On 04/04/12 07:42, Christopher Howard wrote:
> Now, a good compiler might inline the function anyway, even if you don't
> use the "inline" keyword. I'm not trying to push the usage of the
> "inline" keyword, but only to demonstrate my original point: all else
> being equal, at the lowest level code with a function call will actually
> be slightly less efficient (in terms of raw cycles needed) than the
> equivalent code without one. With a small data set, that difference will
> be negligible, but if you had three trillion numbers to crunch, it might
> make a measurable difference.

To the less expert, I want to butt in here and make a point.  While Howard is 
essentially correct, this is not a matter you need to think about.  Not now, and 
probably not for a long time.  Whether your data set is small or "three trillion 
numbers", just write your code.  Get it to work.  Then find out how long it is 
taking.  Determine if that length of time is okay.  If it's taking 1 second on 
your largest dataset, do you really need to go back an optimise it so that it 
takes half a second instead?  (Maybe you do, maybe you don't, it depends on 
server load and how quickly you need the information etc).  What if it's taking 
500ms and you could potentially push it down to 300ms?  Again, it depends.

One your code works, and you can measure it; then, and only then, if it is 
taking too long, worry about optimisation.  Premature optimisation is always a 
waste of your time.  (Manually inlining functions as a matter of course without 
a) making sure your code works and b) having measured it and knowing that you 
need to speed it up; is an example of premature optimisation).  Optimising your 
code risks making it more complex.  It can also make tools that you use to debug 
or otherwise assess your code, harder to use.  The best way to write code to 
make after the fact optimisation easy is (oddly enough) to write lots of small 
functions each which do a specific task that you can explain in < 10 words.  For 
example, go back and see my post about making instant coffee.

So, yes, there is a time cost to calling functions that you wouldn't have if you 
pushed everything into your main function or inlined everything.  It's not 
usually significant.  When you write code, that has lots of short, well defined 
functions, and it's running slowly you can then use a profiler to find out which 
ones are running the slowest.  A profiler will tell you that your program spends 
70% of its time in functionA and 20% of it's time in functionB.  But even this 
is not enough information.  The profiler will also tell you how many times each 
function is called.  If functionA and functionB are called the same (or similar) 
number of times, then (if you need to speed the code up) you should concentrate 
on improving functionA.  If it tells you that functionA is called 10,000,000 
times and functionB is called once (and if you need to speed the code up) you 
might find it more effective to try to speed up functionB first.

   1. The first rule of Optimization Club is, you do not Optimize.
   2. The second rule of Optimization Club is, you do not Optimize without
      measuring.
   3. If your code doesn't do what you want it to do, you have no business
      optimizing it.
   4. If your app is running faster than the underlying transport protocol, the
      optimization is over.
   5. One factor at a time.
   6. Testing will go on as long as it has to.
   7. If this is your first night at Optimization Club, you have to write a test
      case.

When you are thinking about #2 grab a profiler.  For #3 write a test suite.  For 
#7, learn to write tests.

All the best,

     J