我想从一个游戏程序员的角度探讨OOP的一个问题──性能。

现时C++可以说是支持OOP范式中最为常用及高性能的语言。

历史上，OOP大概是60年代出现，而C++诞生于70年代末。现在的硬件和当时的有很大差异，其中最大的问题是内存墙_百度百科。

图1: 处理器和内存的性能提升比较，处理器的提升速度大幅高于内存[2]。图1: 处理器和内存的性能提升比较，处理器的提升速度大幅高于内存[2]。

跟据Numbers Every Programmer Should Know By Year：

图2：2014年计算机几种操作的潜伏期(latency)。图2：2014年计算机几种操作的潜伏期(latency)。

从这些数据，我们可以看出，内存存取成为现代计算机性能的重要瓶颈。然而，这个问题在C++设计OOP编程范式的实现方式之初应该并未能考虑得到。现时的OOP编程有可能不缓存友好(cache friendly)，导致有时候并不能发挥硬件最佳性能。以下描述一些箇中原因。

1. 过度封装

使用OOP时，会把一些复杂的问题分拆抽象成较简单的独立对象，通过对象的互相调用去实现方案。但是，由于对象包含自己封装的数据，一个问题的数据被分散在不同的内存区域。互相调用时很可能会出现数据的cache miss的情况。

2. 多态

在C++的一般的多态实现中，会使用到虚函数表。虚函数表是通过加入一次间接层来实现动态派送。但在调用的时候需要读取虚函数表，增加cache miss的可能性。基本上要支持动态派送，无论用虚函数表、函数指针都会形成这个问题，但如果类的数目极多，把函数指针如果和数据放在一起有时候可放缓问题。

3. 数据布局

虽然OOP本身并无限制数据的布局方式，但基本上绝大部分OOP语言都是把成员变量连续包裹在一段内存中。甚至使用C去编程的时候，也通常会使用到OOP或Object-based的思考方式，把一些相关的数据放置于一个struct之内：

即使不使用多态，我们几乎不加思索地会使用这种数据布局方式。我们通常会以为，由于各个成员变量都紧凑地放置在一起，这种数据布局通常对缓存友好。然而，实际上，我们需要考虑数据的存取模式(access pattern)。

在OOP中，通过封装，一个类的各种功能会被实现为多个成员函数，而每个成员函数实际上可能只会存取少量的成员变量。这可能形式非常严重的问题，例如：

在这种模式下，实阶上只存取了两个成员变量，但其他成员变量也会载入缓存造成浪费。当然，如果在迭代的时候能存取尽量多的成员变量，这个问题可能并不存在，但实际上是很困难的。

如果采用传统的OOP编程范式及实现方式，数据布局的问题几乎没有解决方案。oop所以在[1]里，作者提出，在某些情况下，应该放弃OOP方式，以数据的存取及布局为编程的考虑重中，称作面向数据编程(data-oriented programming, DOP)。

有关DOP的内容就不在此展开了，读者可参考[1]，还有[3]作为实际应用例子。

[1] ALBRECHT, “Pitfalls of Object Oriented Programming”, GCAP Australia, 2009. research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

[2] Hennessy, John L., and David A. Patterson. Computer architecture: a quantitative approach. Elsevier, 2012.

[3] COLLIN, “Culling the Battlefield”, GDC 2011. dice.se/wp-content/uploads/CullingTheBattlefield.pdf

本文来自电脑杂谈，转载请注明本文网址：

http://www.pc-fly.com/a/tongxinshuyu/article-47256-1.html