Question

I’m trying to implement the first calculator. My old code (switch-case) :

enum arithmetic_type{
    add = 0,
    subtract = 1,
    multiply = 2,
    divide = 3
};

inline void calculate(double &var, double value, arithmetic_type type){

    switch(type)
    {
        case add : var += value;break;
        case subtract : var -= value;break;
        case multiply : var *= value;break;
        case divide : var /= value;break;
    }

}

I saw “pointer to function definition” and then had a new idea : Using separate functions instead. Now my code looks like :

typedef void(*arithmetic_type)(double &var, double value); //template

inline void add(double &var, double value){var+=value;} //components
inline void subtract(double &var, double value){var-=value;}
inline void multiply(double &var, double value){var*=value;}
inline void divide(double &var, double value){var/=value;}
////////////////////////////////////////////////////////////////
struct VAR
{
    double var_value;
    arithmetic_type operator_type;
    inline void calculate(double value){operator_type(var_value, value);}
};

I see it’s much simpler than switch-case. And more importantly, I’m going to add some other operators e.g relational operators… So I think this new solution is clearer and also it’s more convenient than the old switch-case solution. 🙂

But I still doubt about code speed & performance. Does it perform faster?

Answer 1

First of all – as a general rule you have finite resources. In many cases your most valuable resource is time of programming. In such case you should go with easiest/most readable version. From description of your problem it looks like you have started optimizing prematurely (unless it is toy example in optimization).

That said in some cases you care about performance. Usually then you have existing implementation but the performance does not meet the goal (say – computation takes days instead of hours). I doubt that ‘simple calculator’ came near close to such problems but lets assume it for the sake of argument. Then there is whole branch of macro-optimalization you can use – i.e. you should think more about big-picture (change of algorithm etc.) rather then small picture (function pointer vs case). First of all you need to find out what is causing slowdown (if something takes 10% of time program is running and you speed it up by 50% the overall improvement will be 5%, on the other hand if you improve the rest of program by 25% the performance will be improved by 22%).

In even more rare cases even after such optimization the performance goal is high enough that your code still don’t match it. IT IS USUALLY ONLY WHEN YOUR PROGRAM IS COMPUTE HEAVY AND RUNS FOR MONTHS OR YEARS ON MANY MACHINES – for example protein folding is worth optimizing in such way while most of the programs, even popular ones, is not. Usually at this point you need to know:

• The exact platform you are optimizing for
• Basic computer architecture (pipelining, ILP, cache architecture, cache-coherence protocol etc.)
• The compiler you are using

If you are in this are it is likely that case/switch performs better because it allows better utilize the branch predictions while using function pointer you are only using BTB. On the other hand if your architecture and you are using very simple C compiler the case/switch might overflow the I-cache (so function pointers will perform better).

---

To sum up:

1. Don’t optimize
2. Don’t optimize yet (for experts only)

While it is true that in some cases you need to optimize usually you are better off starting from macro-optimalization and recognizing what is source of slowdown. If your program is waiting for I/O anyway (case I would suspect with calculator) then noone will ever know if your program replies a ns faster. Similarly if your parser/tokenizer is the bottleneck optimization of execution won’t help much.

If macro-optimalizations are not sufficient and 1% improvement of running time can be worth weeks of your work you might want to look at micro-optimalizations knowing both the processor and compiler.