In C++, should POD-types be used for performance-critical parts, where many instances of the type will be handled?

Question

(In C++) For a type whose instances will be handled in great numbers in performance-critical areas, such as a Vector2 class representing 2D-positions, should such types preferably be made POD? So something like:

struct Vector2f
{
    float x;
    float y;
};

rather than:

struct Vector2f
{
    float x;
    float y;
    float crossProduct();
    float magnitude();
    ... // Etc, functions that could be handy
};

I've read that making types whom you will handle many instances of POD can improve performance, because it is easier for the program to deal with them since it doesn't have to deal with vtables and other things.

When should POD-types be used? Is there a good rule of thumb?

Answer 1

There is no difference in your 2 code examples, both would run at the same speed.

Is there a good rule of thumb?

Yes:

Do not attempt to over-optimize your code.

---

I follow these basic rules:

1. Avoid square root operations, and when required, store the result if needed multiple times.

2. Avoid *, / or % by powers of 2. Use <<, >> and & instead.

3. Use bit fields as much as possible. Parallel condition checks become "all for the cost of one".

4. Try to avoid nested loops, sometimes unavoidable, but if you hit a 3rd or ouch 4th nesting level, consider other ways to accomplish the task, try a tree, grid or other data structure.

5. Always break; or return out of loops early if possible.

6. Avoid recursion, unless the bounds are known and/or maxdepth is provided.

7. If you find yourself reusing the same heap reference a bunch of times: "object.something" or "object->something" store it in a local variable to help with cache locality.

Like every rule, these were made to be broken with discretion.

Beyond these rules, I ask myself: "Is it worth the hassle?" The profiler times will usually answer this question and identify the critical sections for me.

I only then do I optimize the problem areas.

---

To address your "vtable" concern, use virtual sparingly, or simply avoid inheritance in your classes and use static "POD" calls with reference parameters to implement common methods.

This is similar to what the compiler does in the background, only avoiding the run-time lookup table since the classes and calls are concrete(fixed addresses are provided) at compile time.

That is overkill, but to eek out every ounce of performance, this answers your question as asked.