您是否觉得在编写“好的”面向对象的代码与编写非常快速的低延迟代码之间需要权衡？例如，避免在C ++中使用虚函数/多态性的开销等-重写看上去很讨厌但很快的代码等？
我从事的领域是吞吐量，而不是延迟，但它对性能至关重要，我会说“ sorta”。
但是问题是，太多的人完全错误地理解了他们的绩效观念。新手经常会犯错，他们的整个“计算成本”概念模型都需要重新设计，只有算法复杂性才是他们唯一可以正确解决的问题。中间人弄错了很多事情。专家认为有些错误。
使用可以提供诸如高速缓存未命中和分支错误预测之类的指标的准确工具进行测量，可以使该领域中所有专业知识水平的所有人都受到检查。
衡量也是指出无法优化的内容。专家花费的时间通常比新手少，因为他们正在优化真实的热点，而不是基于对可能慢的预感（在极端情况下，可能会诱使人们进行微优化），在黑暗中优化野刺。关于代码库中的所有其他行）。
性能设计
除此之外，性能设计的关键来自接口部分的设计部分。缺乏经验的问题之一是，绝对实现指标往往会在早期发生转变，例如在某些通用上下文中调用间接函数的成本，就好像成本（从优化程序的角度立即理解）视图而不是分支视图）是避免在整个代码库中使用它的原因。
成本是相对的。虽然间接函数调用会产生成本，但是，所有成本都是相对的。如果您花一倍的时间来调用一个循环遍历数百万个元素的函数，则担心此成本就像花费数小时来讨价还价以购买十亿美元的产品，只是得出结论不购买该产品，因为它一分钱太贵了。
粗接口设计
性能的接口设计方面通常会更早地寻求将这些成本推到更粗略的水平。例如，与其为单个粒子支付运行时抽象成本，不如将其推高至粒子系统/发射器的水平，从而有效地将粒子渲染为实现细节和/或仅将此粒子集合的原始数据渲染。
因此，面向对象的设计不一定要与性能设计（无论是等待时间还是吞吐量）不兼容，但是用一种专注于它的语言进行的诱惑就可以建模越来越小的颗粒对象，而最新的优化器无法救命。它无法像通过为软件的内存访问模式产生有效的SoA表示的方式合并代表单个点的类那样的事情。接口设计在粗糙级别上建模的点集合提供了这种机会，并允许根据需要迭代到越来越多的最佳解决方案。这样的设计是为大容量存储器*设计的。
*请注意，这里重点关注内存而不是数据，因为长时间在性能至关重要的区域工作会改变您对数据类型和数据结构的看法，并查看它们如何连接到内存。在这种情况下，除非有固定分配器的帮助，否则二叉搜索树不再仅仅是对数复杂性，例如对于树节点而言可能是完全不同且对缓存不友好的内存块。该视图并没有消除算法的复杂性，但它不再依赖于内存布局。人们还开始将工作迭代视为更多关于内存访问迭代的信息。*
实际上，许多对性能至关重要的设计可以与人类易于理解和使用的高级接口设计概念非常兼容。不同之处在于，在这种情况下，“高级”将涉及内存的大容量聚合，为可能的大量数据建模的接口，并且可能是相当底层的实现。视觉上的类比可能是一辆真正舒适，易于驾驶和操纵，并且在以音速行驶时非常安全的汽车，但是如果您打开引擎盖，里面几乎没有喷火的恶魔。
采用较粗略的设计还趋向于提供更有效的锁定模式并利用代码中的并行性的更简便方法（多线程是一个详尽的主题，在这里我将跳过）。
内存池
低延迟编程的一个关键方面可能是对内存进行非常明确的控制，以提高引用的局部性以及分配和释放内存的总体速度。定制分配器池内存实际上呼应了我们所描述的相同类型的设计思想。专为散装而设计；它的设计是粗略的。它以大块的形式预分配内存，并以小块的方式池化已分配的内存。
这个想法与将昂贵的东西（例如，针对通用分配器分配内存块）推到越来越高的级别完全相同。内存池设计用于批量处理内存。
类型系统隔离内存
任何语言的面向对象的细粒度设计的困难之一是，它经常想引入很多用户定义的类型和数据结构。如果可以动态分配这些类型，则可以将它们分配给很小的一部分。
在C ++中，一个常见的例子是需要多态的情况，自然的诱惑是针对通用内存分配器分配子类的每个实例。
这最终将可能连续的内存布局分解为几乎没有字节的位和片段，这些位和片段分散在整个寻址范围内，从而导致更多的页面错误和高速缓存未命中。
要求最低延迟，无阻塞，确定性响应的领域可能是热点不总是归结为一个瓶颈的地方，在这里，微小的低效率实际上可以真正地“积累”（很多人想象到剖析器错误地检查了它们，但是在延迟驱动的字段中，实际上可能会出现一些罕见的情况，这些情况会导致效率低下的情况累积。造成这种累积的许多最常见原因可能是：过度分配了整个内存中的小块内存。
在Java之类的语言中，如果可能的话，对于瓶颈区域（在紧密循环中处理的区域）使用更多的普通旧数据类型数组会很有帮助，例如数组int（但仍在庞大的高级接口后面）代替，是ArrayList用户定义的Integer对象。这避免了通常伴随后者的内存隔离。在C ++中，如果我们的内存分配模式高效，则不必使结构降级那么多，因为用户定义的类型可以在那里连续分配，甚至在通用容器的上下文中也可以。
融合在一起的记忆
此处的解决方案是为同质数据类型甚至可能跨同质数据类型提供一个自定义分配器。当微小的数据类型和数据结构在内存中展平为位和字节时，它们具有同质的性质（尽管有一些不同的对齐要求）。当我们不以内存为中心的思维方式看待它们时，编程语言的类型系统就会“想要”将潜在连续的内存区域分割/分离成很小的散乱块。
堆栈利用这种以内存为中心的焦点来避免这种情况，并有可能在其中存储用户定义类型实例的任何可能的混合组合。尽可能多地利用堆栈是一个好主意，因为堆栈的顶部几乎总是位于高速缓存行中，但是我们还可以设计内存分配器，这些内存分配器在没有LIFO模式的情况下模仿其中的某些特征，从而将不同数据类型的内存融合为连续的即使是更复杂的内存分配和释放模式也可以使用块。
当处理连续的内存块（例如，重复访问相同的缓存行，相同的页面）时，现代硬件被设计为处于顶峰。有连续性的关键字，因为这仅在周围有感兴趣的数据时才有用。因此，性能的许多关键（也是困难）是将隔离的内存块再次融合在一起，成为连续的块，这些块在逐出之前将全部访问（所有周围的数据都是相关的）。编程语言中特别是用户定义类型的丰富类型系统在这里可能是最大的障碍，但是我们总是可以在适当的时候通过自定义分配器和/或更大的设计来解决问题。
丑陋
很难说“丑”。这是一个主观指标，在性能非常关键的领域工作的人会开始将其“美”的概念更改为更多面向数据的主题，并将重点放在大量处理事物的界面上。
危险的
“危险”可能会更容易。通常，性能趋向于达到较低级别的代码。例如，要实现内存分配器，就必须深入数据类型并以危险的原始位和字节级别工作，这是不可能的。结果，它可以帮助提高对这些对性能至关重要的子系统中仔细的测试过程的关注，并根据所应用的优化级别来扩展测试的彻底性。
美人
但是所有这些都将在实现细节级别上。在经验丰富的大型和注重性能的思维定式中，“美”都倾向于转向界面设计而不是实现细节。寻找“美丽的”，可用的，安全的，有效的接口，而不是由于接口设计更改时可能发生的耦合和级联损坏而导致的实现，将成为指数级更高的优先级。实施可以随时换出。我们通常会根据需要并通过测量指出性能。界面设计的关键是在足够粗糙的水平上建模，以便为此类迭代留出空间而不会破坏整个系统。
实际上，我建议经验丰富的人将重点放在对性能至关重要的开发上，这通常会把重点放在安全性，测试，可维护性上，而通常只是SE的门徒，因为具有大量性能的大规模代码库-关键子系统（粒子系统，图像处理算法，视频处理，音频反馈，光线跟踪器，网格引擎等）将需要密切关注软件工程，以避免淹没在维护噩梦中。绝非偶然的是，最令人惊讶的高效产品通常也有最少数量的错误。
TL; DR
无论如何，这是我的主题，范围从真正关键性能的领域的优先事项，可以减少延迟并导致微小的效率低下的累积，以及实际上构成“美”（当以最有效的方式看待事物时）。