Encapsulation v Performance

Simple question:

I really like the idea of encapsulation, but I really don't know if it is worth it is a performance critical situation.

For exam开发者_开发知识库ple:

x->var;

is faster than

x->getVar();

because of the function calling overhead. Is there any solution that is both fast AND encapsulated?

getVar() in all possibility could be inlined. Even if there is a performance penalty, the benefits of encapsulation far outweigh the performance considerations.

There's no overhead if the function is inlined.

On the other hand, getters are a often code smell. And a bad one. They stick to the letters of encapsulation, but violate its principles.

• "There's no overhead if the getVar function is inlined"
• "If getVar() is simply return var; and is inline and non-virtual the two expressions should be optimized to the same thing"
• "getVar() in all possibility could be inlined"

Can Mr Rafferty make the assumption that the code will be inlined? Not "should be" or "could be". In my opinion that's a problem with C++: it's not especially WYSIWYG: you can't be sure what code it will generate. Sure there are benefits to using oo but if execution efficiency (performance) is important C++ (or C# or Java) is not the obvious choice.

On another topic

There's a lot of talk about "Premature Optimization" being the root of all evil and, since no one gets what the premature is about a lot of programmers think that optimization is the root of all evil.

In these cases I find it helpful to bring out the original quote so everyone may see what they've been missing (not to say misunderstanding and misquoting):

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

Most people attribute the quote to Tony Hoare (father of QuickSort) and some to Donald Knuth (Art of Computer Programming).

An informative discussion as to what the quote may or may not mean may be found here: http://ubiquity.acm.org/article.cfm?id=1513451

You can write inline accessor functions.

You are right in that there often is a tradeoff between clean object oriented design and high performance. But do not make assumptions. If you go into these kinds of optimizations, you have to test every change for performance gains. Modern compilers are incredibly good at optimizing your code (like the comment from KennyTM says for your example), so do not fall into the trap of Premature Optimization.

It's important to realise that modern optimisers can do a lot for you, and to use C++ well you need to trust them. They will optimise this and give identical performance unless you deliberately code the accessors out-of-line (which has a different set of benefits: e.g. you can modify the implementation and relink without recompiling client code), or use a virtual function (but that's logically similar to a C program using a function pointer anyway, and has similar performance costs). This is a very basic issue: so many things - like iterators, operator[] on a vector etc. would be too costly if the optimiser failed to work well. All the mainstream C++ compilers are mature enough to have passed this stage many, many years ago.

As others have noted, the overhead is either negligible, or even entirely optimized away. Anyway it is very unlikely that the bottleneck lies in these kind of functionss. And to add insult to injury, if you find there is a performance problem with the access pattern, if you use direct access you are out of luck, if you use accessor functions you can easily update to better performing patterns like e.g. caching.