但是对于基于性能的软件（即程序执行速度有多快），此OOP会对它不利吗？
通常是！！！但...
换句话说，在许多不同对象之间的许多引用，或者使用许多类中的许多方法，是否可能导致“繁重的”实现？
不必要。这取决于语言/编译器。例如，一个优化的C ++编译器（如果您不使用虚函数）通常会将您的对象开销压缩为零。您可以执行一些操作，例如在int该处写一个包装器，或在一个普通的旧指针上编写一个作用域的智能指针，其执行速度与直接使用这些普通的旧数据类型一样快。
在其他语言（如Java）中，对象有一些开销（在很多情况下通常很小，但是在某些情况下带有真正的小对象却是天文数字）。例如，Integer效率远远低于int（占用16个字节，而不是64位上的4个字节）。然而，这不仅仅是公然的浪费或任何类似的东西。作为交换，Java提供了诸如统一地对每个用户定义类型进行反射的功能，以及覆盖未标记为的任何功能的能力final。
但是，让我们以最理想的情况为例：优化的C ++编译器可以将对象接口优化到零开销。即使这样，OOP仍会经常降低性能并阻止其达到顶峰。这听起来像是一个完全的悖论：怎么可能？问题在于：
接口设计与封装
问题在于，即使编译器可以将对象的结构压缩到零开销（这对于优化C ++编译器来说至少通常是正确的），细粒度对象的封装和接口设计（以及累积的依赖项）通常会阻止旨在由群众聚集的对象的最佳数据表示（对于性能至关重要的软件通常是这种情况）。
举个例子：
class Particle
{
public:
...
private:
double birth; // 8 bytes
float x; // 4 bytes
float y; // 4 bytes
float z; // 4 bytes
/*padding*/ // 4 bytes of padding
};
Particle particles[1000000]; // 1mil particles (~24 megs)
假设我们的内存访问模式是简单地依次遍历这些粒子，然后在每个帧中反复移动它们，将它们从屏幕的各个角落弹起，然后呈现结果。
我们已经看到，birth当粒子连续聚集时，正确对齐成员所需的4字节填充开销非常大。已经有约16.7％的内存浪费了用于对齐的死空间。
这似乎没有意义，因为这些天我们有千兆字节的DRAM。但是，即使涉及到当今最强大的计算机，当涉及到CPU缓存（L3）的最慢和最大区域时，通常也只有8 MB 。我们所能容纳的越少，就重复访问DRAM而言，我们为此付出的代价就越多，事情就越慢。突然，浪费16.7％的内存似乎不再是一件小事。
我们可以轻松消除这种开销，而不会影响字段对齐：
class Particle
{
public:
...
private:
float x; // 4 bytes
float y; // 4 bytes
float z; // 4 bytes
};
Particle particles[1000000]; // 1mil particles (~12 megs)
double particle_birth[1000000]; // 1mil particle births (~8 bytes)
现在我们将内存从24兆减少到20兆。通过顺序访问模式，计算机现在将更快地消耗此数据。
但是，让我们birth更仔细地看一下这个领域。假设它记录了粒子出生（创建）的开始时间。想象一下，仅在首次创建粒子时才访问该字段，并且每10秒查看一次粒子是否应该死亡并在屏幕上的随机位置重生。在那种情况下，birth是一个寒冷的领域。在我们的性能关键循环中无法访问它。
结果，实际的关键性能数据不是20兆字节，而是12兆字节的连续块。我们经常访问的实际热内存已缩小到一半！期望比我们最初的24兆字节解决方案有显着的提速（不需要衡量-已经做过这种事一千次了，但是如有疑问，请放心）。
但是请注意我们在这里所做的。我们彻底破坏了这个粒子对象的封装。现在，其状态在Particle类型的专用字段和单独的并行数组之间划分。这就是颗粒状的面向对象设计的出路。
当局限于单个非常细粒度的对象（如单个粒子，单个像素，甚至单个4分量矢量，甚至可能是游戏中的单个“生物”对象）的界面设计时，我们无法表达最佳数据表示形式如果猎豹站在一个2平方米的小岛上，那将浪费它的速度，这就是非常精细的面向对象设计通常在性能方面所做的工作。它将数据表示限制为次优性质。
进一步说，假设我们只是在移动粒子，因此我们实际上可以在三个单独的循环中访问它们的x / y / z字段。在这种情况下，我们可以从具有AVX寄存器的SoA风格SIMD内在函数中受益，该寄存器可以并行向量化8个SPFP操作。但是要做到这一点，我们现在必须使用以下表示形式：
float particle_x[1000000]; // 1mil particle X positions (~4 megs)
float particle_y[1000000]; // 1mil particle Y positions (~4 megs)
float particle_z[1000000]; // 1mil particle Z positions (~4 megs)
double particle_birth[1000000]; // 1mil particle births (~8 bytes)
现在我们进行粒子模拟，但是看看粒子设计发生了什么。它已经完全拆除，我们现在正在研究4个并行数组，没有任何对象可以对其进行聚合。我们的面向对象Particle设计已经走了。
这在我对性能至关重要的领域中工作过很多次，在这些领域中，用户要求速度，而正确性是他们要求更高的一件事。这些小小的面向对象的设计必须拆除，并且级联的损坏通常要求我们使用缓慢的折旧策略来实现更快的设计。
解
上面的情况仅提出了面向对象的精细设计问题。在这些情况下，由于SoA代表，热/冷字段拆分，顺序访问模式的填充减少，我们常常最终不得不拆除结构以表示更有效的表示（填充有时对随机访问的性能有所帮助）在AoS情况下会出现这种模式，但几乎总是阻碍顺序访问模式），等等。
但是，我们可以采用我们所确定的最终表示形式，并仍然为面向对象的接口建模：
// Represents a collection of particles.
class ParticleSystem
{
public:
...
private:
double particle_birth[1000000]; // 1mil particle births (~8 bytes)
float particle_x[1000000]; // 1mil particle X positions (~4 megs)
float particle_y[1000000]; // 1mil particle Y positions (~4 megs)
float particle_z[1000000]; // 1mil particle Z positions (~4 megs)
};
现在我们很好。我们可以获得喜欢的所有面向对象的东西。猎豹在全国范围内尽其所能地奔跑。我们的界面设计不再使我们陷入瓶颈。
ParticleSystem甚至可能是抽象的并且使用虚函数。现在要讨论了，我们要在粒子收集级别而不是每个粒子级别支付开销。如果我们在单个粒子级别对对象进行建模，则开销是其他情况的1 / 1,000,000。
所以这是在处理大负荷真正的性能关键领域的解决方案，并为所有类型的编程语言（这种技术的好处C，C ++，Python和Java的，JavaScript的，Lua中，斯威夫特等）。而且它不容易被标记为“过早优化”，因为这与界面设计和体系结构有关。我们无法编写将单个粒子建模为对象的代码库，并且将大量客户依赖项Particle's公共接口，然后稍后再改变主意。当被调用来优化遗留代码库时，我已经做了很多事情，最终可能需要花费数月的时间仔细重写成千上万行代码才能使用更大的设计。理想情况下，这可以影响我们预先设计事物的方式，前提是我们可以预料到很重的负载。
在许多性能问题中，尤其是与面向对象设计有关的问题，我一直以某种形式或其他形式回应。面向对象的设计仍然可以与最高需求的性能需求兼容，但是我们必须稍微改变一下思考方式。我们必须给猎豹提供一定的运行空间，以使其尽可能快地运行，而如果我们设计几乎不存储任何状态的小物件，这通常是不可能的。