计划效率

Question

我想知道，与任何编程语言中的结构化编程方法相比，采用面向对象的方法解决问题是否会对程序效率产生影响，特别是在c ++中。

Answer 1

也许。也许不是。

您可以编写有效的面向对象代码。您可以编写效率低下的结构化代码。

这取决于应用程序，代码编写的程度以及代码的优化程度。通常，您应该编写代码，使其具有良好，干净，模块化的体系结构并且设计良好，然后如果您遇到性能问题，则优化导致性能问题的热点。

使用面向对象编程，使用它是有意义的，并使用结构化编程，使用它是有意义的。您不必在一个和另一个之间做出选择：您可以同时使用它们。

Answer 2

我记得早在20世纪90年代早期，当C ++年轻的时候就有关于此的研究。如果我没记错的话，那些接受（编写好的）C ++程序并用C语言重新编写它们的人的速度提高了大约15％。那些接受C程序并用C ++重新编码的人，并将C的命令式样式修改为OO风格（但相同的算法），C ++获得了相同或更好的性能。观察到C语言被转化为面向对象的风格变得更加有条理，这就解释了明显的矛盾。你在C语言中所做的事情是因为代码太多而且做得更好也很容易在C ++中正确完成。

回想起这个我对这个结论感到疑惑。第二次编写程序总会产生一个更好的程序，所以它不一定是OO风格的必要条件。今天的计算机体系结构设计有对OO程序完成的常见操作的硬件支持，并且编译器在使用指令方面变得更好，所以我认为，无论1992年虚拟函数调用的开销是多少，它今天都要小得多。 / p>

Answer 3

如果你非常小心避免它，就没有必要。如果你只是采用最简单的方法，使用动态分配，虚函数和（特别是）按值传递对象，那么肯定是效率低下。

Answer 4

不一定是这样。算法是最重要的。我同意封装会减慢你的速度，但编译器会在那里进行优化。

Answer 5

如果这是计算机科学论文中的问题，你会说不。

然而，在真实的开发环境中，如果正确使用OOP范例，这往往是正确的。原因是在实际开发过程中，我们通常需要维护我们的代码库，以及OOP范例可以帮助我们的时间。与C类结构化编程相比，OOP的一个优点是在OOP中更容易使代码可维护。当代码更易于维护时，它意味着更少的bug，更少的时间来修复错误，减少实现新功能所需的时间。最重要的是，我们将有更多时间专注于应用程序的效率。

Answer 6

问题不是技术问题，而是心理问题。它是通过简化它来鼓励你做的。

要做一个世俗的比喻，它就像一张信用卡。它比写支票或使用现金更有效率。如果是这样，为什么人们会用信用卡遇到这么多麻烦？因为它们非常容易使用，所以滥用它们。不要过度使用好东西需要很好的纪律。

OO滥用的方式是

• 创建太多“抽象层”

• 创建过多的冗余数据结构

• 鼓励使用通知式代码，尝试在冗余数据结构中保持一致性。

最好将数据结构最小化，如果必须是冗余的，则能够容忍暂时的不一致。

增加： 作为OO鼓励的事物的例证，这是我在性能调整中有时看到的：有人设置SomeProperty = true;。这听起来很无辜，对吧？好吧，它可以波及包含该对象的对象，通常是通过难以追踪的多态性。这可能意味着某些列表或字典需要添加到其中或从中删除。这可能意味着某些树或列表控件需要添加或删除或改组控件。这可能意味着正在创建或销毁窗口。它也可能意味着需要在数据库中更改某些内容，这可能不是本地的，因此需要执行一些I / O或互斥锁定。

它真的会变得疯狂。但谁在乎？它是 抽象 。

Answer 7

可能存在：OO方法往往更接近于解耦方法，其中不同的模块不会在彼此内部进行探索。它们仅限于公共接口，并且总是存在潜在的成本。例如，调用getter而不是直接检查变量;或者默认调用虚函数，因为对象的类型对于直接调用来说不够明显。

尽管如此，有几个因素可以减少这一点作为有用的观察结果。

1. 编写良好的结构化程序应具有相同的模块性（即隐藏实现），因此会产生相同的间接成本。在C中调用函数指针的成本可能与在C ++中调用虚函数的成本非常相似。

2. 现代JIT，甚至在C ++中使用内联方法，都可以消除间接成本。

3. 成本本身可能相对较小（通常每次指令调用只需几个简单的操作）。在实际工作以紧密循环方式完成的程序中，这将是微不足道的。

4. 最后，更加模块化的风格使程序员可以解决更复杂但更有希望的复杂算法，而不会产生低级错误。