封装与性能
简单的问题：
我真的很喜欢封装的想法，但我真的不知道在性能关键的情况下是否值得。
例如：
x->var;
比 更快
x->getVar();
由于函数调用开销， 。有没有既快速又封装的解决方案？
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 example:
x->var;
is faster than
x->getVar();
because of the function calling overhead. Is there any solution that is both fast AND encapsulated?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
正如其他人所指出的，开销可以忽略不计，甚至完全优化掉。
无论如何，瓶颈不太可能出现在这些功能上。雪上加霜的是，如果您发现访问模式存在性能问题，如果您使用直接访问，那么您就不走运，如果您使用访问器功能，您可以轻松更新为性能更好的模式，例如缓存。
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.
getVar() 在所有可能的情况下都可以内联。即使存在性能损失，封装的好处也远远超过了性能考虑。
getVar() in all possibility could be inlined. Even if there is a performance penalty, the benefits of encapsulation far outweigh the performance considerations.
如果函数是内联的，则没有任何开销。
另一方面，getters 通常是一种代码味道 。而且是一件坏事。他们坚持封装的字母，但违反了其原则。
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.
Rafferty 先生可以假设代码将被内联吗？不是“应该”或“可能”。在我看来，这是 C++ 的一个问题：它并不是特别所见即所得：你无法确定它将生成什么代码。当然，使用 oo 有好处，但如果执行效率（性能）很重要，C++（或 C# 或 Java）并不是显而易见的选择。
关于另一个话题，
有很多人都在谈论“过早优化”是万恶之源，而且由于没有人明白过早优化的含义，因此许多程序员认为优化是万恶之源。
在这些情况下，我发现拿出原始引用很有帮助，这样每个人都可以看到他们所遗漏的内容（更不用说误解和错误引用）：
“我们应该忘记小的效率，大约 97% 的时间：过早的优化但我们不应该放弃这关键的 3% 的机会。”
大多数人将这句话归因于 Tony Hoare（快速排序之父），还有一些人归因于 Donald Knuth（计算机编程艺术）。
关于这句话的含义或含义的信息讨论可以在这里找到：http:// /ubiquity.acm.org/article.cfm?id=1513451
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
您是对的，在干净的面向对象设计和高性能之间经常需要进行权衡。但不要做出假设。如果您进行此类优化，则必须测试每项更改以提高性能。现代编译器非常擅长优化您的代码（就像 KennyTM 在您的示例中所说的那样），因此不要陷入 过早优化。
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.
您可以编写内联访问器函数。
You can write inline accessor functions.
重要的是要认识到现代优化器可以为您做很多事情，并且要很好地使用 C++，您需要信任它们。他们将对此进行优化并提供相同的性能，除非您故意对访问器进行离线编码（这具有不同的好处：例如，您可以修改实现并重新链接而无需重新编译客户端代码），或者使用虚拟函数（但这就是无论如何，逻辑上类似于使用函数指针的 C 程序，并且具有类似的性能成本）。这是一个非常基本的问题：如果优化器不能很好地工作，那么很多东西——比如迭代器、向量上的operator[]等都会代价太高。所有主流的C++编译器都足够成熟，很多很多年前就已经通过了这个阶段。
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.