Question

OK, here’s what I want :

• I have written several REALLY demanding functions (mostly operating on bitmaps, etc) which have to be as fast as possible
• Now, let’s also mention that these functions may also be grouped by type, or even by the type of variable on which they operate.
• And the thing is, apart from the very implementation of the algorithms, what I should do – from a technical point of view – in order not to mess up the speed.

And now, I’m considering the following scenarios :

• Create them as simple functions and just pass the necessary parameters as arguments
• Create a class (for ‘grouping’/organisation purposes) and just declare them as static
• Create class by type, e.g. Create a class for working on bitmaps, create a new instance of that Class for every bitmap (e.g. Bitmap* myBitmap = newBitmap(1010);, and operate on it with its inner methods (e.g. myBitmap->getFirstBitSet())

Now, which of these approaches is the fastest? Is there really any difference between straight simple functions and Class-encapsulated static functions, performance-wise? Any other scenario that would be preferable, which I haven’t mentioned?

---

Sidenote : I’m using the clang++ compiler, for Mac OS X 10.6.8. (if that makes any difference)

Answer 1

At CPU level, there is only one kind of function, and it very much ressemble the C kind. You could craft your own, but…

As it turns out, C++ being built with efficiency in mind maps most functions directly to call instructions:

• a namespace level function is like a regular C function
• a static method is like a namespace level function (from a call point of view)
• a non-static method is very similar to a static method, except an implicit this parameter is passed on top of the other parameters (one pointer)

All those 3 have the exact same kind of performance.

On the other hand, virtual methods have a slight overhead. There was a C++ technical report on performance which estimated the overhead compared to a non-virtual method between 10% and 15% (from memory) for empty functions. Meaning that for any function with meat inside (ie, doing real work), the overhead itself is close to getting lost in the noise. The real cost comes from the inhibition of inlining unless the virtual call can be deduced at compile-time.