封装性能

简单的问题：封装性能

我真的很喜欢封装的想法，但我真的不知道是否值得它是一个性能危急的情况。

例如：

x->var;

快于

x->getVar();

因为函数调用的开销。有没有解决方案既快速又封装？

来源

2010-11-09 Alexander Rafferty

如果'getVar'内联函数有没有开销。 – 2010-11-09 09:03:18

如果'getVar（）'仅仅是'return var;'并且是内联和非虚的，那么这两个表达式应该被优化为相同的东西。 – kennytm 2010-11-09 09:03:20

这个问题不仅仅是一个简单的upvote。 – zeboidlund 2011-12-24 07:35:11

“没有开销，如果getVar内联函数”
“如果getVar（）仅仅是返回VAR;并内嵌和非虚两人的表情应该进行优化，以同样的事情”
“getVar（）在所有可能的情况下都可以内联”

Mr Rafferty能否假设代码将被内联？不是“应该”或“可能”。在我看来，这是C++的问题：它不是特别所见即所得：你不能确定它会产生什么代码。确定使用oo有好处，但是如果执行效率（性能）很重要C++（或C＃或Java）不是明显的选择。

另一个话题

有很多的谈“过早优化”是一切罪恶和根源，因为没有人会过早的是关于什么的很多程序员认为优化是一切的根源邪恶。

在这种情况下，我觉得它带来了有益的原帖所以每个人都可以看到他们已经错过了什么（不说误解和错误地引用）：

“我们应该忘记小的效率，说一下97％的时间：不成熟的优化是万恶之源，但我们不应该在这个关键的3％中放弃我们的机会。“

大多数人属性报价托尼·霍尔（快速排序的父亲）和一些以高德纳（计算机程序设计艺术）。

的翔实的讨论，以什么报价可能会或可能并不意味着可以在这里找到：http://ubiquity.acm.org/article.cfm?id=1513451

来源

2010-11-09 10:17:38

这句话最重要的是：_你怎么知道那些性能至关重要的3％？_一般的答案是：_You在分析你的应用程序之前，不知道那些3％在哪里。所以__你需要profile_，为了做到这一点，你必须有一个应用程序配置文件。 _首先你必须写一个应用程序___，并且你应该写这个，这样它就很容易编写和维护___。在超过3％的应用程序中牺牲封装不会为您带来任何性能，但会使成本飙升并且窃取剖析所需的时间。 – sbi 2010-11-09 16:37:44

主要问题不在于OP是否可以“假定函数将被内联”，而是_这个函数是否真的对这个函数有影响。根据你的引用，在97％的情况下，函数是否内联___无关紧要。在所有情况下，97％的人都认为这是有害的，因为你浪费宝贵的项目时间，应该花费在重要的事情上（比如找到3％并优化它们）。 – sbi 2010-11-09 16:42:48

每当（或者我应该说97％的时间）某人想要了解优化的优缺点时，它会让我感到震惊，一般来说，这些答案中的97％很快指出优化的方式是多么的浪费，以及如何进行优化现在编译器非常棒，开始误引一个完全合理的报价并曲解它。显然假设写的人需要被强行“帮助”出他假定的错误概念。我发现这令人不安，该名男子提出了一个有效的问题，并立即被知道所有人所知。 – 2010-11-12 08:10:57

您可以编写内联存取器函数。

来源

2010-11-09 09:02:54

这实在是一个评论，而不是问题的答案。请使用“添加评论”为作者留下反馈。 – 2012-08-19 12:45:40

@RostyslavDzinko感谢您对我一年多前回答的关注。然而，在我的愚见中，尽管简洁明了，但答案却是如此。 – 2012-08-20 10:58:45

所有可能的getVar（）都可以内联。即使存在性能损失，封装的好处远远超过性能考虑。

来源

2010-11-09 09:03:19 Chubsdad

通常...... – 2010-11-09 09:30:23

你是对的，因为在清洁的面向对象的设计和高性能之间往往有一个折衷。但不要做出假设。如果您进行这些优化，您必须测试每个变更以获得性能提升。现代编译器非常擅长优化你的代码（就像KennyTM的评论所说的那样），所以不要陷入Premature Optimization的陷阱。

来源

2010-11-09 09:08:59

还有没有开销如果函数内联。

另一方面，getters are a often code smell。还有一个不好的。他们坚持封装的信件，但违反其原则。

来源

2010-11-09 09:10:21 sbi

+1，并且爱你的新头像:) – 2010-11-09 09:43:16

认识到现代优化器可以为您做很多事情，并且很好地使用C++，您需要信任它们，这一点很重要。他们会优化这一点，并提供相同的性能，除非您故意对访问器进行非线性编码（具有不同的优点：例如，您可以修改实现并重新链接而无需重新编译客户端代码），或者使用虚拟功能（但这是在逻辑上类似于使用函数指针的C程序，并且具有相似的性能成本）。这是一个非常基本的问题：如果优化器无法正常工作，那么很多东西 - 比如载体上的迭代器，运算符[]，等等都会太昂贵。所有主流的C++编译器已经足够成熟，可以在许多年前通过这个阶段。

来源

2010-11-09 09:11:03

正如其他人已经指出的那样，开销可以忽略不计，甚至完全优化。无论如何，瓶颈在这些功能中是不太可能的。如果您发现访问模式存在性能问题，如果您使用直接访问，那么您运气不好，如果使用访问器函数，则可以轻松更新以获得更好的性能模式，例如，缓存。

来源

2010-11-09 09:16:32

回答

相关问题