1 简介
性能为王：十年前如此，现在当然也是如此。根据domo.com-2017的数据，2017 年全球每天产生 2.5 万亿字节的数据。statista.com-2024预测，这一数字将在 2024 年达到每天 400 万亿字节。在我们这个日益以数据为中心的世界里，信息交换的增长需要更快的软件和更快的硬件。
得益于摩尔定律，软件程序员几十年来一直顺风顺水。软件供应商可以依靠新一代硬件来加快软件产品的速度，即使他们不花费人力物力来改进代码。这种策略已经行不通了。通过观察下图，我们可以发现单线程性能增长正在放缓。从 1990 年到 2000 年，SPECint 基准的单线程性能增长了约 25 到 30 倍，这主要得益于 CPU 频率的提高和微体系结构的改进。
从 2000 年到 2010 年，CPU 的单线程性能增长较为平缓（4 到 5 倍）。当时，由于功耗、散热挑战、电压扩展限制（Dennard Scaling）和其他基本问题，时钟速度在 4GHz 左右达到顶峰。尽管时钟速度停滞不前，架构上的进步持续进行：改进的分支预测、更深的流水线、更大的缓存以及更高效的执行单元。
从 2010 年到 2020 年，单线程性能仅增长了 2 到 3 倍。在此期间，CPU 制造商开始更多地关注多核处理器和并行性，而不是仅仅提高单线程性能。
现代处理器的晶体管数量持续增加。例如，苹果芯片的晶体管数量从 M1 的 160 亿个增加到 M2 的 200 亿个、M3 的 250 亿个，再到 M4 的 280 亿个，时间跨度大约为四年。晶体管数量的增长使制造商能够为处理器增加更多内核。到 2024 年，你可以买到在一个 CPU 插槽上拥有 100 多个逻辑内核的高端服务器处理器。这令人印象深刻。遗憾的是，这并不总能带来更好的性能。很多时候，应用程序的性能并不会随着 CPU 内核的增加而提高。
每一代硬件都能显著提升性能的情况已不复存在，因此我们必须开始更多地关注代码的运行速度。在寻求提高性能的方法时，开发人员不应依赖硬件。相反，他们应该开始优化应用程序的代码。
“今天的软件效率极低；现在又到了软件程序员真正擅长优化的黄金时期"。- 美国企业家兼投资人马克-安德森（Marc Andreessen）
1.1 为什么软件运行缓慢？
如果世界上所有的软件都能有效利用所有可用的硬件资源，那么这本书就不会存在。我们不需要在软件方面做出任何改变，只需依靠现有处理器所能提供的资源即可。但你已经知道现实并非如此，对吗？现实情况是，现代软件的效率极低。公共云中的普通服务器系统通常运行的代码优化程度很低，消耗的电能超过了其本应消耗的电能（增加了碳排放并引发了其他环境问题）。下表总结了对两个 4096 乘 4096 矩阵进行乘法运算的程序在性能工程方面的提速。经过多次优化后，程序运行速度提高了 60,000 多倍。之所以提供这个例子，并不是要挑剔 Python 或 Java（它们都是很棒的语言），而是要打破软件默认性能 “足够好 ”的观念。大多数程序都在1-5的范围内。源代码级改进的潜力是巨大的。- for i in xrange(4096):
- for j in xrange(4096):
- for k in xrange(4096):
- C[i][j] += A[i][k] * B[k][j]
- 性能分级
- Parallel loops (并行循环): 指的是将循环中的迭代任务分配给多个处理器核心或线程并行执行，以缩短计算时间。这是并行计算中最基础和常见的形式。
- Parallel divide and conquer (并行分治法): 这是一种将问题分解成更小的、相似的子问题，递归地解决这些子问题，然后将结果组合起来解决原问题的方法。并行分治法利用多个处理器同时解决不同的子问题，从而实现并行化。
- Plus vectorization (加上向量化): 向量化是一种利用SIMD（Single Instruction, Multiple Data，单指令多数据）指令的技术，可以同时对多个数据元素执行相同的操作。 “加上向量化”意味着在并行化的基础上，进一步利用向量化来提高每个核心的计算效率。
- Plus AVX intrinsics (加上AVX内部函数): AVX (Advanced Vector Extensions，高级向量扩展) 是一组SIMD指令集，提供了更宽的向量寄存器和更多的指令，可以进行更复杂的向量运算。 AVX intrinsics 是在C/C++等语言中直接使用AVX指令的函数，相比于编译器自动向量化，使用 intrinsics 可以更精确地控制向量化过程，并获得更高的性能。 “加上AVX内部函数”意味着在向量化的基础上，使用AVX intrinsics 来进一步优化代码，发挥AVX指令集的优势。
版本实现运行时间 (s)GFLOPS绝对加速比相对加速比峰值百分比 (%)1Python25,552.480.0051—0.002Java2,372.680.0581110.80.013C542.670.253474.40.034并行循环69.801.9693667.80.245并行分治3.8036.1806,72718.44.336加向量化1.10124.91423,2243.514.967加AVX指令集0.41337.81262,8062.740.45在双插槽英特尔至强 E5-2666 v3 系统上运行的两个 4096 乘 4096 矩阵乘法程序的性能工程提速，内存总容量为 60 GB。
来源：There’s plenty of room at the Top: What will drive computer performance after Moore’s law?
每个版本代表对原始Python代码的连续改进。“运行时间”指的是该版本的运行时间。“GFLOPS”表示每秒执行的64位浮点运算操作数量，单位为十亿次。“绝对加速比”是相对于Python版本的时间比率，而我们以额外一位精度显示的“相对加速比”是指相对于前一个版本的时间比率。“峰值百分比”则是该版本GFLOPS数值相对于计算机峰值性能（835 GFLOPS）的百分比。更多详情请参阅方法部分。
是什么阻碍了系统在默认情况下实现最佳性能。以下是一些最重要的因素：
现代 CPU 执行指令的速度快得令人难以置信，而且一代比一代好。但是，如果用于执行工作的指令不是最佳指令，甚至是多余指令，那么它们仍然无法完成很多工作。
处理器无法神奇地将次优代码转化为性能更好的代码。例如，如果我们执行冒泡排序，CPU 不会尝试识别它并使用更好的替代指令（如 quicksort）。它只会盲目地执行任何指令。
如今的编译器已经非常智能，但仍有可能生成次优代码。编译器在消除冗余工作方面非常出色，但在做出更复杂的决定（如矢量化）时，编译器可能无法生成最佳代码。性能专家往往能提出超出编译器能力的巧妙方法来矢量化循环。当编译器需要决定是否执行代码转换时，它们依赖于复杂的成本模型和启发式方法，而这些方法可能并不适用于所有可能的情况。例如，对于编译器是否应始终将函数内联到其被调用的地方这个问题，就没有二元对立的 “是 ”或 “否 ”的答案。这通常取决于编译器应该考虑的许多因素。此外，除非编译器绝对确定这样做是安全的，否则不能进行优化。编译器可能很难证明某个优化在所有可能的情况下都是正确的，因此不允许进行某些转换。最后，编译器一般不会尝试 “英雄式 ”的优化，如转换程序使用的数据结构。
一些开发人员过于痴迷于算法复杂度分析，这导致他们选择具有最佳算法复杂度的流行算法，尽管该算法对于特定问题来说可能不是最有效的。就插入排序和 quicksort 这两种排序算法而言，就平均情况的大 O 符号而言，后者显然更胜一筹：插入排序的算法复杂度为 O(N2)，而 quickSort 的算法复杂度仅为 O(N log N)。然而，对于相对较小的 N 大小（最多 50 个元素），插入排序的性能要优于 quickSort。复杂性分析无法解释各种算法的所有底层性能影响，因此人们只是将其封装在隐含常量 C 中，而这有时会对性能产生很大影响。只计算用于排序的比较和交换，忽略了高速缓存缺失和分支错误预测，而这在今天实际上是非常昂贵的。如果不在目标工作负载上进行测试，就盲目相信大 O 符号，可能会导致开发人员走上错误的道路。因此，针对某个问题的最知名算法并不一定是针对所有可能输入的实际性能最好的算法。
除了上述限制外，编程范式也会造成一些开销。优先考虑代码清晰度、可读性和可维护性的编码实践可能会降低性能。高度通用化和可重用的代码会引入不必要的复制、运行时检查、函数调用、内存分配等。例如，面向对象编程中的多态性通常使用虚拟函数来实现，这会带来性能开销。上述所有因素都会对软件征收 “性能税”。通常情况下，我们有很多机会来调整软件的性能，以充分发挥其潜力。
1.2 为何关注性能？
除了硬件单线程性能增长放缓外，还有其他一些商业原因也需要关注性能。在 PC 时代，由于低效软件在用户电脑上运行，用户要为低效软件付出代价。软件供应商并没有优化其应用程序代码的直接动力。随着 SaaS（软件即服务）和云计算的出现，软件速度慢的成本又转嫁到了软件供应商身上，而不是用户身上。如果你是像 Meta 或 Netflix 这样的 SaaS 公司 ，不管你是在内部硬件上运行服务还是使用公共云，你都要为服务器消耗的电费买单。效率低下的软件会直接削减你的利润和市场估值。根据 Synergy Research Group 的数据，2020 年全球云服务支出超过 1000 亿美元:
而根据 Gartner 的数据 ，2025年将超过 8247亿美元:
服务类型2023年支出2023年增长率 (%)2024年支出2024年增长率 (%)2025年支出2025年增长率 (%)云应用基础设施服务 (PaaS)142,93419.5172,44920.6211,58922.7云应用服务 (SaaS)205,99818.1247,20320.0295,08319.4云业务流程服务 (BPaaS)66,1627.572,6759.882,26213.2云桌面即服务 (DaaS)2,70811.43,06213.13,43712.3云系统基础设施服务 (IaaS)143,30219.1180,04425.6232,39129.1总市场561,10417.3675,43320.4824,76322.1多年来，性能工程一直是书呆子的小众领域，但现在它正逐渐成为主流。许多公司已经意识到性能工程的重要性，并愿意为这项工作支付高额报酬。
达到第 4 级性能相当容易, 用一种本地编程语言编写程序，在多个线程之间分配工作，选择一个好的优化编译器，就能达到目的。不幸的是，你的程序性能将比最佳目标慢 200 倍左右。本书中的方法侧重于从应用程序中榨取最后一点性能。第6和第7就是这种改造的结果。将要讨论的改进类型通常提速不超过 10%。但是，不要低估 10%速度提升的重要性。SQLite 今天的普及并不是因为其开发人员某天将其速度提高了 50%，而是因为他们多年来一丝不苟地进行了数百次 0.1% 的改进。这些微小改进的累积效应才是与众不同之处。
对于在云中运行的大型分布式应用程序而言，微小改进的影响非常重要。根据Hennessy，2018的数据，2018 年，谷歌在实际运行云的计算服务器上花费的资金与在电力和冷却基础设施上花费的资金大致相同。能效是一个非常重要的问题，可以通过优化软件来改善。
“在这样的（谷歌）规模下，了解性能特征变得至关重要--即使是性能或利用率上的微小改进，也能转化为巨大的成本节约"。Kanev等人，2015年
除了云成本，还有另一个因素在起作用：人们如何看待缓慢的软件。谷歌报告称，搜索延迟 500 毫秒会导致流量减少 20%。对于雅虎来说，页面加载速度提高 400 毫秒，流量就会增加 5-9%。这些例子证明，服务运行速度越慢，使用的人就越少。
在云服务之外，还有许多其他对性能要求极高的行业，如人工智能 (AI)、高性能计算 (HPC)、高频交易 (HFT)、游戏开发等也需要性能工程。此外，性能不仅是高度专业化领域的要求，也与通用应用程序和服务息息相关。如果不能满足性能要求，我们日常使用的许多工具就不会存在。例如，集成到 Microsoft Visual Studio IDE 中的 Visual C++ IntelliSense必须在几毫秒内解析整个源代码库。这样的功能必须反应迅速，并在用户输入新代码时提供有效的连续性。
“并非所有快速的软件都是世界一流的，但所有世界一流的软件都是快速的。性能是杀手锏"。Shopify 首席执行官托比-卢克（Tobi Lutke）说。
我希望不言而喻，人们讨厌使用速度慢的软件，尤其是当他们的工作效率因此而下降时。下表显示，大多数人认为 2 秒或更长时间的延迟是 “漫长的等待”，并会在等待 10 秒后转而使用其他软件。如果您想留住用户的注意力，您的应用程序就必须反应迅速。
Interaction ClassHuman PerceptionTargetUpper Bound快速最小可察觉延迟100ms200ms交互式快，但不足以称为快速300ms500ms暂停不快，但仍感觉响应迅速500ms1秒等待由于工作量大而不快1秒3秒长时间等待不再感觉响应迅速2秒5秒困定长时间等待 - 用于不可避免的长/复杂场景5秒10秒长时间运行长时间操作 - 用户可能会多任务处理（在操作期间切换）10秒30秒来源：Delivering Delightful Performance for More Than One Billion Users Worldwide
有时，快速工具的应用并非最初设计的目的。例如，虚幻和 Unity 等游戏引擎可用于建筑、三维可视化、电影制作和其他领域。由于游戏引擎性能卓越，它们自然成为需要二维和三维渲染、物理模拟、碰撞检测、声音、动画等应用的首选。
“快速工具不仅能让用户更快地完成任务，还能让用户以全新的方式完成全新类型的任务"。Nelson Elhage在他的博客中写道 。
1.3 什么是性能分析？
您是否曾与同事争论过某段代码的性能？那么您可能知道预测哪段代码效果最好有多难。现代处理器内部有如此多的活动部件，即使是对代码的微小调整也会引发明显的性能变化。在优化应用程序时，依靠直觉通常会导致随意的 “修正”，而不会对性能产生真正的影响。
缺乏经验的开发人员有时会修改代码，并声称代码运行速度会更快。其中一个例子是将 i++（后置递增）替换为 ++i（前置递增）。在一般情况下，这种改动不会对生成的代码产生任何影响：所有优秀的优化编译器都会识别出 i 的前一个值没有被使用，并消除多余的副本。本书的第一条建议是：不要完全依赖直觉。一定要测量。
世界上流传的许多微优化技巧在过去是有效的，但现在的编译器已经学会了它们。此外，有些人倾向于过度使用传统的XOR交换技巧。实际上，简单的 std::swap 就能产生等效或更快的代码。这种偶然的改动很可能不会提高应用程序的性能。找到正确的调整位置应该是仔细性能分析的结果，而不是直觉或猜测。
性能分析是一个收集程序执行信息并对其进行解释以寻找优化机会的过程。对程序源代码的任何修改都应通过分析和解释收集到的数据来实现。我们将向您展示如何使用性能分析技术来发现优化机会，即使是在一个庞大而陌生的代码库中。性能分析方法有很多。根据问题的不同，有些方法比其他方法更有效。随着经验的积累，您将对何时使用每种方法形成自己的策略。
1.4 什么是性能调优？
找到性能瓶颈只是工程师工作的一半。下半部工作是正确修复瓶颈。有时，只需修改程序源代码中的一行，就能大幅提升性能。错过这样的机会可能会造成很大的浪费。性能分析和调优就是要找到并修复这一行。
要充分利用现代 CPU 的所有计算能力，就必须了解它们是如何工作的。或者像性能工程师喜欢说的那样，你需要有 “机械共情”(Mechanical sympathy)。这个词是从赛车界借来的。它的意思是，赛车手如果对汽车的工作原理了如指掌，就会比不了解汽车原理的竞争对手更有优势。这同样适用于性能工程。我们不可能了解现代 CPU 运行的所有细节，但我们需要对其有一个良好的心智模型，以榨取最后一点性能。
这就是我所说的底层优化。这是一种考虑到底层硬件能力细节的优化。高层次优化更多涉及应用层逻辑、算法和数据结构。正如你在书中看到的，大多数低级优化都可以应用于各种现代处理器。要成功实现底层优化，需要对底层硬件有充分的了解。
“在后摩尔时代，使代码运行得更快，尤其是使代码与运行硬件相匹配，将变得越来越重要"。莱森等人，2020 年
过去，软件开发人员更多的是机械共情的，因为他们经常需要处理硬件实现的细微差别。在个人电脑时代，开发人员通常直接在操作系统之上进行编程，中间可能会使用一些库。随着世界进入云时代，软件堆栈变得更深、更广、更复杂。堆栈的顶层（大多数开发人员在其上工作）与硬件的距离越来越远。这种演变的负面影响是，现代应用程序的开发人员对运行其软件的实际硬件的亲和力降低了。本书将帮助你建立与现代处理器的紧密联系。
Donald Knuth 有一句名言：“过早优化是万恶之源”。推迟性能工程可能会为时已晚，造成的恶果不亚于过早优化。对于从事性能关键型项目的开发人员来说，了解底层硬件的工作原理至关重要。从一开始，软件的性能特性就必须与正确性和安全性一起成为首要目标。性能不佳与安全漏洞一样容易导致产品夭折。ClickHouse DB 是一个成功软件产品的例子，它是围绕一个小型但非常高效的核心构建的。
性能工程是一项重要而有价值的工作，但可能非常耗时。事实上，性能优化是一场没有终点的游戏。总有一些东西需要优化。开发人员不可避免地会遇到收益递减的问题，即预期的工程成本无法证明进一步的改进是合理的。知道何时停止优化是性能工作的一个重要方面。
参考资料
- 软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
- 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce
- python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
- Linux精品书籍下载 https://www.cnblogs.com/testing-/p/17438558.html
1.5 本书内容
编写本书的目的是帮助开发人员更好地了解应用程序的性能，学会发现和消除效率低下的问题。
- 为什么我的更改会导致性能下降2倍？
- 我们的客户抱怨我们的应用程序速度太慢。我该如何调查？
- 为什么我的手写压缩算法比传统算法慢？
- 我是否充分优化了程序？
- 我的平台上有哪些性能分析工具？
- 有哪些技术可以减少缓存未命中和分支预测错误的次数？
我希望在本书结束时，你能够回答这些问题。
本书分为两部分。第一部分（第 2-7 章）教你如何发现性能问题，第二部分（第 8-13 章）教你如何解决性能问题。
- 第 2 章讨论公平的性能实验及其分析。它介绍了性能测试和结果比较的最佳实践。
- 第 3 章介绍 CPU 微体系结构，仔细研究英特尔的 Golden Cove 微体系结构。
- 第 4 章介绍性能分析中使用的术语和指标。在本章末尾，我们介绍了一个案例研究，其中包括在四个实际应用中收集的各种性能指标。
- 第 5 章探讨了最流行的性能分析方法。我们介绍了剖析工具的工作原理以及它们可以收集哪些数据。
- 第 6 章探讨了基于英特尔、AMD 和 ARM 的现代 CPU 为支持和增强性能分析而提供的功能。本章介绍了这些功能的工作原理以及它们有助于解决哪些问题。
- 第 7 章概述了 Linux、Windows 和 MacOS 上最流行的性能分析工具。
- 第 8 章介绍优化内存访问、缓存友好代码、数据结构重组和其他技术。
- 第 9 章是关于优化计算；它探讨了数据依赖、函数内联、循环优化和矢量化。
- 第10章是无分支编程，用于避免分支错误预测。
- 第11章介绍机器代码布局优化，如基本块放置、函数拆分和配置文件引导优化。
- 第 12 章包含前四章未涉及的优化主题，但仍然重要到足以在本书中占有一席之地。在本章中，我们将讨论特定于 CPU 的优化，研究几个与微体系结构相关的性能问题，探讨用于优化低延迟应用程序的技术，并就如何调整系统以获得最佳性能提出建议。
- 第 13 章讨论分析多线程应用程序的技术。该章深入探讨了优化多线程应用程序所面临的一些最重要的挑战。我们提供了五个实际多线程应用程序的案例研究，并解释了为什么它们的性能不会随着 CPU 线程数的增加而增加。我们还讨论了缓存一致性问题（如 “错误共享”）和一些专门用于分析多线程应用程序的工具。
本书提供的示例主要基于开源软件： Linux 作为操作系统，基于 LLVM 的 Clang 编译器用于 C 和 C++ 语言，以及各种可以构建和运行的开源应用程序和基准。原因不仅在于这些项目的流行，还在于它们的源代码都是开放的，这使我们能够更好地了解它们工作的基本机制。这对于学习本书介绍的概念尤其有用。这并不意味着我们永远不会展示专有工具。例如，我们广泛使用英特尔® VTune™ Profiler。
有时，通过各种提示迫使编译器生成所需的机器代码，可以获得极具吸引力的提速。在本书中，你会发现很多这样的例子。虽然先前的编译器经验对性能工作有很大帮助，但在大多数情况下，您不必成为编译器专家也能提高应用程序的性能。大多数优化都可以在源代码层面完成，无需深入研究编译器源代码。
1.6 本书未讨论哪些内容？
系统性能取决于不同的组件： CPU、DRAM、I/O 和网络设备等。应用程序可能会从调整系统的不同组件中受益，这取决于瓶颈所在。一般来说，工程师应分析整个系统的性能。然而，影响系统性能的最大因素是其核心，即 CPU。因此，本书主要侧重于从 CPU 的角度进行性能分析。我们还广泛讨论了内存子系统，但没有探讨 I/O 和网络性能。
同样，软件堆栈包括许多层，例如固件、BIOS、操作系统、库和应用程序的源代码。不过，由于大多数较低层次并不在我们的直接控制之下，因此主要重点将放在源代码层面。
本书的范围不会超出单个 CPU插槽，因此我们不会讨论分布式、NUMA 和异构系统的优化技术。本书不讨论使用 OpenCL 和 openMP 等解决方案将计算卸载到加速器（GPU、FPGA 等）的问题。
我试图让本书适用于大多数现代 CPU，包括英特尔、AMD、苹果和其他基于 ARM 的处理器。如果本书没有涵盖你最喜欢的架构，我很抱歉。不过，书中讨论的许多原理也适用于其他处理器。同样，本书中的大多数示例都是在 Linux 上运行的，但大多数时候这并不重要，因为同样的技术对在 Windows 和 macOS 操作系统上运行的应用程序也有好处。
本书中的代码片段是用 C 或 C++ 编写的，但在很大程度上，本书中的思想可以应用于其他编译为本地代码的语言，如 Rust、Go 甚至 Fortran。由于本书针对的是贴近硬件运行的用户模式应用程序，我们将不讨论托管环境，如 Python、Java。
最后，我假定读者可以完全控制自己开发的软件，包括选择使用的库和编译器。因此，本书不涉及调整购买的商业软件包，例如调整 SQL 数据库查询。
1.7 练习
作为本书的补充材料，我开发了 “性能忍者”，这是一个免费的在线课程，您可以在其中练习低级性能分析和调整。该课程可在以下网址获取：perf-ninja。该课程包含一系列实验作业，主要针对特定的性能问题。每个实验任务可能需要 30 分钟到 4 小时不等，这取决于您的背景和实验任务本身的复杂程度。
根据 GitHub 仓库的名称，我们将使用 perf-ninja 来指代在线课程。在每章末尾的 “问题和练习 ”部分，你可能会发现来自 perf-ninja 的作业。例如，当你看到 perf-ninja::warmup，它对应于 GitHub 仓库中名称为 “Warmup ”的实验作业。我们鼓励你解决这些难题来巩固你的知识。
您可以在本地机器上完成作业，也可以将代码修改提交到 GitHub 进行自动验证和基准测试。如果您选择后者，请按照资源库 “开始 ”页面上的说明进行操作。我们还在全书中使用 perf-ninja 中的示例。这可以让你在自己的机器上重现特定的性能问题并进行实验。
1.8 本章小结
- CPU 单线程性能的提升速度已不如几十年前。当每一代硬件都能显著提升性能时，开发人员就应该开始优化软件代码。
- 现代软件效率极低。公共云中的普通服务器系统通常会运行优化不佳的代码，消耗比本应消耗更多的电力，从而增加碳排放并引发其他环境问题。
- 某些限制因素阻碍了应用程序充分发挥其性能潜力。CPU 无法神奇地加速缓慢的算法。编译器远不能为每个程序生成最佳代码。大 O 符号并不总是性能的良好指标，因为它没有考虑硬件的具体情况。
- 多年来，性能工程一直是书呆子的小众领域。但现在，随着软件供应商意识到优化不佳的软件会对他们的底线造成影响，性能工程正逐渐成为主流。
- 人们绝对讨厌使用速度慢的软件，尤其是当他们的工作效率因此而下降时。并非所有速度快的软件都是世界一流的，但所有世界一流的软件都是速度快的。性能是杀手锏。
- 与过去 40 年相比，软件调优正变得越来越重要，在不久的将来，它将成为提高性能的关键驱动力之一。不应低估底层性能调优的重要性，哪怕只是 1% 的改进。这些微小改进的累积效应才是决定性因素。
- 要榨取最后一点性能，你需要对现代 CPU 的工作原理有一个良好的心理模型。
- 预测某段代码的性能几乎是不可能的，因为影响现代平台性能的因素太多了。在实施软件优化时，开发人员不应依赖直觉，而应仔细分析性能。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
