[ernstsson]

So as a summary to the comments above; Function pointers between files isn't bad for performance if we can't do link time optimization. When link time optimization really becomes widely available, it's still not bad? Just the step in the middle that could be affected then? Thinking out loud here, any thoughts on this? I usually opt for structure over performance before profiling proves otherwise, but I still find this to be an interesting topic.

[exDM69]

> So as a summary to the comments above; Function pointers between files isn't bad for performance if we can't do link time optimization.

No. Function pointers between files are horrible for performance. Do not use them if you're on the fast path. A function pointer (across translation units) not only destroys the compiler's ability to optimize, it also kills your cpu's instruction cache. You can solve the problem by using inline functions and apply __attribute__((always_inline)) or similar if required. If in doubt, check the assembly output of your compiler to verify that all calls have been inlined.

Link time optimization is the cure. It's not widely available at the moment, but maybe in a few years it will be more important. If you work in a relatively isolated piece of software, it's possible that you can use a compiler with link time optimization and get the perf gains today.

Meanwhile, don't use function pointers across translation units if you know you're on the fast path. If you're optimizing something that is profiled to be slow, look for function pointers because getting rid of them can give a big boost.

> I usually opt for structure over performance before profiling proves otherwise, but I still find this to be an interesting topic.

You should always go for structure over performance except when you should not.