Looking at the code, I find it strange why you would use modulo.

You could simplify things by using for(0...10), couldn't you?

But maybe this is only the prototype for something bigger, which will
have to use it.

At second glance, why don't you need & to asign function pointers to the functions??

p[n] = &one...and so forth.

Last issue:

Why do you set up functions 2 to n, when you only test function 0 and 1.

You are right, I am wrong. I thought you would use num[i]%10 to call the functions, but you use a different value. Therefore everything is fine :-)

Actually all numbers 0 to 9 %10 will turn out to be 0, not even 1.

Therefore the test is maybe not correct.

You should assign at least numbers to 100 to num[i] to get a result.

If you want to make a game without "if"s then, you're going to quickly be overwhelmed, but feel free to try it. Remember, a game isn't the real world. It's a simulation... an approximation. And every time you approximate something, imagine you're putting a nice piecewise function together with an if statement.

That being said:

1 - Look at the assembly, and for the love of God turn off optimizations. For all you know all of those turn into the same code.

2 - If/switch/etc are all the same anyway. It's a thousand times worse to incur a context switch than it is to use any branching. So what you're getting is a CPU with a gigantic "velocity" but a tiny "acceleration" and every time you decide to switch contexts it has to stop and start the process over again. So there are things entirely out of your control (like task scheduling) that will have more effect on your program than your decision for using switches/ifs/etc in most cases.

3 - Never assume a benchmark reflects real-world performance.

I can't figure out what it is that you're trying to benchmark here. None of these code constructs should be the bottleneck in your code, but even if they were, I don't think that your tests would accurately measure their performance. It's also the kind of thing that doesn't have a single right answer. What might be right on your hardware for a simple test might be wrong on your hardware with a real world situation, or even on my hardware with the same simple test. Don't waste your time with this kind of thing unless you have a lot of it and plan to focus your career on low-level optimization (generally not very worthwhile in 99% of applications, but there are some unique systems where it is vital and you could find employment working with those if you learn your stuff...). For the most part, I can't help thinking "why would you even?"

Benchmarking without a real world example is useless. 99% of the time if you make a guess about what is wrong with your program that is causing it to be so slow you will be wrong (at least until you have 10 or 20 years of experience under your belt and have already been wrong enough to know). Generally the only reliable way to speed a program up these days is to run it through a profiler and let the profiler tell you where all of the time is spent. Computers have gotten exponentially more complicated than they were 20 years ago. There may have been a time when this question was a valid one to ask, but these days it isn't really... It's a waste of the OP's time, IMO, and it's irresponsible to encourage it instead of pointing him in a more appropriate direction...

Sure, but enabling link-time optimization when you want to avoid inlining functions defined in other files would a bit be silly, don't you think?

I'm all for curiosity, however, optimization should be the last step, not the first one. A program that works slowly gets shipped. A program that goes fast and doesn't do anything doesn't... and in five years a slow program runs fast on new computers. (e.g. Adobe Photoshop)

Thanks for all of the feedback!

But it seems like some of you assume that I have a bottleneck in my code, but there is no code except what I posted in the first post. I thought I made it clear.

I wrote that code just to see how fast each of the different ways of determining what function to run was.

I thought that feeding an index to an array of function pointers would be the fastest, I did it with and without optimizations and I found that in this particular case on my machine the switch was fastest. This makes sense to me now because you lovely people explained to me how compilers can use a jump list. I was under the impression that it would check from top to bottom in the switch and with the ifs.

I wrote the above code purely out of curiosity, and I'm pleased to see the results and all the feedback I got, thank you guys!

My thinking was that if I had each of the different ways of determining what function to run in a loop, the differences in performance between them would add up and it would be more clear which one was fastest.

What I gathered from the results and what I've read in this thread is that there isn't any major performance difference, and that in fact the compiler could be doing the same thing with all of the three approaches.

I also know that the results I got only apply to my machine, I did try to do this on a couple of different machines I got a bit different results but on most of them the switch was the fastest.

I'd like to repeat that I did this purely out of curiosity, most of the things I do are out of curiosity, I love reinventing the wheel, it gives me a deeper understanding of how it works and why it works.

Sorry if this post is a bit messy, I was in a bit of a hurry when writing it.

But thanks guys, I really appreciate it!

Oh, ok I see what you mean now.