本文档概述了编写高性能Go代码的最佳实践。
虽然有些讨论会提高单个服务的速度（通过缓存等），但设计高性能的分布式系统已经超出了这项工作的范围。在监控和分布式系统设计方面已经有很好的文章，它包含了一套完全不同的研究和设计权衡理论。
所有内容将根据CC-BY-SA进行许可。
本书分为以下几节:
- 1) 编写高性能软件的基本技巧
- * CS 101-level的东西
- 2) 编写快速软件的技巧
- * 关于如何从Go获得最佳效果的Go-specific章节
- 3) 编写*真正*快速软件的高级技巧
- * 当你优化的代码不够快时
-
我们可以总结这三个部分:
我先把这个放在第一位，是因为这真的是最重要的一步。你真的应该这么做吗？
每个优化都有成本。通常，这个成本是用代码复杂度或认知负载来承担的 - 优化后的代码很少比优化前的版本简单。
但另一方面，我称之为“优化经济学”。作为程序员，你的时间是宝贵的。你可以为你的项目工作的机会成本，哪些Bug需要修复，以及需要添加哪些功能。优化的工作是很有趣的，但并不总是正确的选择。性能是一种特性，但交付和正确性也是如此。
选择最重要的工作。有时它不是一个实际的CPU优化，而是一个用户体验。就像添加进度条一样简单，或者在渲染页面后通过在后台执行计算来提高页面的响应速度。
有时这是显而易见的:在三小时内完成的报告在一小时完成可能不太有用。
仅仅因为容易优化并不意味着它是值得优化的。忽略low-hang的效果是一种有效的发展战略。
把这看作是优化你的时间。
选择要优化的内容以及何时优化，你可以在“软件质量”和“开发速度”之间移动滑块。
人们无意识地重复说名言——“过早的优化是万恶之源”，但他们错过了它的主要内容。
“程序员浪费了大量的时间来思考或者担心程序中非关键部分的速度，而这些效率的尝试实际上在考虑调试和维护时会产生很大的负面影响。我们应该忘记为了小的性能使用的97％的时间：过早的优化是万恶之源，但我们不应该在这个关键的3％中放弃我们的优化机会。“ - Knuth
附：https : //www.youtube.com/watch?time_continue=429&v=3WBaY61c9sE
“你应该优化吗？”是的，但是只有当问题很重要时，程序真的太慢了，并且能够在保证正确性，稳健性和清晰度的同时变得更快。“ - 编程实践，Kernighan and Pike
BitFunnel性能评估 有一些数字可以使这种权衡更加明确。想象一下假设搜索引擎需要跨越多个数据中心的30,000台机器，这些机器每年的成本约为1,000美元。如果你可以将软件的速度提高一倍，这可以为公司节省每年1500万美元。即使只有一个开发人员花费整整一年时间才能将性能提高也只会付出1％的代价。
在绝大多数情况下，程序的大小和速度不是问题。最简单的优化不必这样做。第二个最简单的优化就是购买更快的硬件。
如果你决定要改变你的程序，请继续阅读。
在介绍具体细节之前，我们先谈谈优化的一般过程。
优化是一种重构形式。但是，每一步不是改进源代码的某些方面（代码重复，清晰度等），而是可以提高性能的某些方面：降低CPU，内存使用率，延迟等。这种改进通常以可读性为代价。这意味着除了一套全面的单元测试（以确保你的更改没有破坏任何内容）之外，你还需要一套很好的基准测试，以确保您的更改对性能产生预期的影响。你必须能够验证您的更改是否真的在降低CPU。有时候你认为会改善性能的变化实际上会变成零或负变化。在这些情况下，务必确保撤消修改的程序。
源代码中遇到过的最好的评论是什么？- Stack Overflow
- //
- //亲爱的维护者:
- //
- //当你完成试图“优化”这个程序，
- //并且已经意识到了什么可怕的错误时，
- //请增加以下计数器作为给后人的警告：
- //
- //total_hours_wasted_here = 42
- //
你使用的基准测试必须正确，并为代表性工作负载提供可重复的数字。如果单个的运行差异太大，则会使得小的改进更难以发现。你将需要使用benchstat或等效的统计测试，而不能只是用眼睛去看(请注意，使用统计测试无论如何都是一个好主意)。应该记录运行基准测试的步骤，并且应该向存储库提交任何自定义脚本和工具，并提供如何运行它们的说明。要注意需要很长时间才能运行的大型基准测试套件:它会使开发迭代变慢。
还要注意，任何可以测量的东西都可以优化。确保你正在衡量正确的事情。
下一步是决定你正在优化什么。如果目标是改进CPU，那么什么是可接受的速度。你想要将当前的性能提高2倍吗？10倍？你能否说它是“小于时间T的大小为N的问题”？你想减少内存使用量吗？多少钱？对于内存使用情况的变化，可以接受的速度有多慢？你愿意放弃什么来换取较低的空间需求？
优化服务延迟是一个棘手的问题。整本书都是关于如何对Web服务器进行性能测试的。主要问题是：对于单个函数，对于给定的问题规模，性能相当一致。对于webservices，你没有一个单一的性能数字。一个适当的Web服务基准套件将为给定的需求/秒级别提供延迟分布。这篇演讲很好地概述了Gil Tene的一些问题："如何不去测量延迟" by Gil Tene
TODO：请参阅后面的关于优化Web服务的部分
绩效目标必须具体。你会（几乎）总是能够更快地做出一些事情。优化往往是一个收益递减的游戏。你需要知道何时停止。你要付出多少努力才能完成最后一点工作。你愿意做出这样的代码是多么难以维护？
Dan Luu之前提到的BitFunnel性能评估的演讲显示了一个使用粗略计算来确定目标性能数据是否合理的例子。
TODO：编程珠玑有“Fermi Problems”。从Jeff Dean's 幻灯片可以了解
对于绿地开发，你不应该把所有的基准和性能数字都留到最后。很容易说“我们稍后会修复”，但如果性能非常重要，那么从一开始就将是一个设计考虑因素。在解决性能问题时所需的任何重大体系结构更改在截止日期前将过于冒险。请注意，在开发过程中，重点应放在合理的程序设计，算法和数据结构上。在更低层次的堆栈优化应该等到开发周期晚些时候才能获得更完整的系统性能视图。你在系统不完整时执行的任何完整系统配置文件都会对完成系统中瓶颈的位置给出偏斜视图。
TODO：如何避免/发现软件写得不好的情况下的“凌迟”。
作为CI的一部分，基准测试是很难的，因为嘈杂的因素，甚至不同的CI盒子，那么很难获取性能指标。一个好的基础是让开发人员运行基准测试（在适当的硬件上）并将其包含在提交消息中，专门用于处理性能问题。对于那些只是提普通补丁的人来说，尽量在代码审查中捕捉性能下降。
TODO：如何跟踪一段时间的性能表现？
编写你可以测试的代码。你可以在较大的系统上执行分析。你可以通过基准测试测试孤立的部分。你需要能够提取并设置足够的环境上下文，以便基准测试足够并具有代表性。
你的目标是什么和目前的表现之间的差异也会让你知道从哪里开始。如果你只需要10％-20％的性能改进，那么可以通过一些实施调整和较小的修复来实现。如果你需要一个10倍或更多的因子，那么用一个左移代替一个乘法不会削减它。这可能会要求你的堆栈上下进行更改。
良好的性能工作需要从系统设计，网络，硬件(CPU，缓存，存储)，算法，调整和调试等多个不同层面的知识。在时间和资源有限的情况下，考虑哪个级别能够提供最大的改进:它并不总是算法或程序调优。
一般而言，优化应该从上到下进行。系统级别的优化将比表达级别的影响更大。确保你在适当的水平上解决问题。
本书主要讨论如何减少CPU使用率，减少内存使用量并减少延迟。很高兴指出你很少能做到这三点。也许CPU时间更快，但现在你的程序使用更多的内存。也许你需要减少内存空间，但现在该程序需要更长的时间。
阿姆达尔定律告诉我们要关注瓶颈。如果你将运行时间仅占5％的代码速度提高一倍，那么整个程序的速度只提升了2.5％。但是，将运行时间占80％的代码加速10％，整体运行时间将提高近8％。配置文件将有助于确定实际花费的时间。
在做优化时，你想减少CPU必须完成的工作量。快速排序比冒泡排序更快，因为它能以更少的步骤解决相同的问题(排序)。这是一个更高效的算法。这样就减少了CPU完成相同任务所需完成的工作。
像编译器优化一样，程序调优通常只会在整个运行时间中造成一点小小的负担。大的胜利几乎总是来自算法改变或数据结构的改变，这是你的程序组织方式的根本转变。编译器技术有所改进，但速度很慢。Proebsting定律表明，编译器每18 年的性能翻倍，这与摩尔定律(稍微误解了解释)形成鲜明对比，该定律使处理器性能每18 个月翻一番。算法改进在更大的范围内工作。从1991年到2008年，混合器整数规划算法提高了30,000倍 有关更具体的示例，请考虑此故障（link：https://medium.com/@buckhx/unwinding-uber-s-most-efficient-service-406413c5871d）取代优步博客文章中描述的蛮力地理空间算法，使用更适合于所提交任务的更专业的算法。没有编译器开关可以提供相同的性能提升。
TODO：在gttse07.pdf中优化浮点FFT和MMM算法的差异
分析器可能会告诉你，大量的时间都花在了特定的例程上。这可能是一个昂贵的例程，或者它可能是一个便宜的例程，只是被调用许多次。你可以先看看是否可以减少调用的次数或完全不调用，而不是立即尝试优化这个例程。我们将在下一节讨论更具体的优化策略。
三个优化问题:
Jon Bentley在1982年的作品“编写高效程序”将程序优化视为一个工程问题:基准。分析。提高。校验。迭代。他的一些技巧现在由编译器自动完成。程序员的工作是使用编译器无法做到的转换。
本书的摘要如下:
和程序调整规则: https://web.archive.org/web/20080513070949/http://www.cs.bell-labs.com/cm/cs/pearls/apprules.html
在考虑对程序进行更改时，有两个基本选项:你可以更改数据，也可以更改代码。
改变你的数据意味着增加或改变你正在处理的数据的表示。从性能角度来看，其中一些最终会改变与数据结构的不同方面相关的O()。
增加数据结构的想法:
TODO:“缓存”可能不是键值对，只是指向你工作的地方。这可以像“搜索手指”一样简单
这些都是数据结构层面“做更少工作”的明确例子。他们都花费空间。大多数情况下，如果你针对CPU进行优化，程序将使用更多的内存。这是经典的时空交易
如果你的程序使用太多的内存，也可以换个方式。减少空间使用量以换取更多计算。而不是存储的东西，每次计算它们。你还可以压缩内存中的数据，并在需要时随时对其进行解压缩。
小内存软件是一本网上可获取的书籍，涵盖了减少程序使用内存空间的技术。虽然它最初是针对嵌入式开发人员编写的，但这些想法适用于处理大量数据的现代硬件的程序。
我们稍后会详细讨论数据布局。
现代计算机和存储器层次结构使空间/时间的权衡不太明确。查找表很容易在内存中“远离”(因此访问成本很高)，使得每次需要时重新计算一次值都会更快。
这也意味着基准测试通常会显示由于缓存争用而导致生产系统无法实现的改进(例如，查找表在基准测试期间位于处理器缓存中，但在真实系统中使用时总是会被“真实数据”冲刷。哈希表实际上直接解决了这个问题，比较了满足和无约束的处理器缓存上的性能。参见Jump Hash paper论文中的图4和图5。
TODO:如何模拟满足的缓存，显示增量成本
另一个要考虑的方面是数据传输时间。通常，网络和磁盘访问非常缓慢，因此能够加载压缩块的速度将比获取数据后解压缩数据所需的额外CPU时间快得多。一如既往，基准。二进制格式通常比文本格式更小且更快解析，但代价是不再是人类可读的格式。
对于数据传输，转移到一个不那么有趣的协议，或者增加API以允许部分查询。例如，增量查询而不是每次都被迫获取整个数据集。
如果你不更改数据，另一个主要选项是更改代码。
最大的改进很可能来自算法变化。这与使用快速排序将气泡排序替换为从O(n ^ 2)排序到O(n log n)或使用映射查找替换通过过去是小O(n)的数组的线性扫描等效(O (1))。
最大的改进可能来自算法变化。这相当于用quicksort（O(nlogn)）替换O(n^2)的冒泡排序或者通过哈希查找（O(1)）替换数组（O(n)）的线性扫描。
这就是软件如何变慢。最初设计用于一种用途的结构被重新用于未设计的东西。这是逐渐发生的。
直观地掌握不同的大O级别是很重要的。为你的问题选择正确的数据结构。你不必一直刮刮胡须，但是这样做可以防止很久以后才会发现的愚蠢的性能问题。
基本的复杂类别是:
链接:http://bigocheatsheet.com
假设你需要搜索未分类的数据集。“我应该用二分搜索”，你知道一个二分搜索O(log n)比O(n)线性扫描快。但是，二分查找需要对数据进行排序，这意味着你需要先对它进行排序，这将花费O(n log n)时间。如果你正在进行大量搜索，那么分类的前期成本将会得到回报。另一方面，如果你主要做查询，也许有一个数组是错误的选择，你最好支付O(1)查找地图的代价。
选择最简单的合理数据结构并继续。这是用于编写“非慢速软件”的CS 101。这应该是您的默认开发模式。如果您知道需要随机访问，请不要选择链接列表。如果您知道需要按顺序遍历，请不要使用地图。需求变化，你不能总是猜测未来。对工作量做出合理的猜测。
http://daslab.seas.harvard.edu/rum-conjecture/
类似问题的数据结构在做一件工作时会有所不同。随着插入的发生，二叉树每次排序一次。未排序的数组插入速度更快但未排序:最后，“敲定”你需要一次完成排序。
当编写一个供其他人使用的包时，避免每个用例都要优先考虑的诱惑。这将导致代码不可读。按设计的数据结构实际上是单一用途的。你既不能读懂头脑，也不能预测未来。如果用户说“你的软件包对于这个用例太慢”，一个合理的答案可能是“然后在这里使用这个软件包”。一揽子计划应该“做得很好”。
有时混合数据结构将提供你需要的性能改进。例如，通过分段数据，你可以将搜索范围限制在一个存储桶中。这仍然支付O(n)的理论成本，但常数会更小。当我们进行编程调整时，我们将重新审视这些调整。
在讨论大O符号时，人们忘记了两件事
其一，涉及到一个不变的因素。具有相同算法复杂度的两种算法可以具有不同的常数因子。想象一下，循环遍历一个列表100次，而仅循环一次。即使两者都是O（n），也有一个恒定的因子是100倍。
这些常数因素是为什么即使合并排序，快速排序和排列所有O(n log n)，每个人都使用快速排序，因为它是最快的。它具有最小的常数因子。
第二件事是大O只说“随着n增长到无穷大”。它谈到了增长趋势，“随着数字变大，这是主导运行时间的增长因素。” 它没有提到实际的表现，也没有说明它如何表现小n。
经常有一个分界点，在这个分界点以下，木材算法更快。Go标准库sort包的一个很好的例子。大多数时候它使用快速排序，但是当分区大小降到12个元素以下时，它会进行shell排序传递，然后进行插入排序。
对于某些算法，常数因子可能非常大，以致此截点可能比所有合理的输入都大。也就是说，O（n ^ 2）算法对于所有可能处理的输入都比O（n）算法快。
这也是另一种方式：例如，即使小输入的基准变慢，选择使用更复杂的数据结构来给出O（n）缩放而不是O（n ^ 2）。这也适用于大多数无锁数据结构。它们通常在单线程情况下较慢，但在多线程使用它时更具可扩展性。
现代计算机中的存储器层次结构将问题混淆了一点，因为高速缓存更喜欢将片段扫描到追踪指针的有效随机访问的可预测访问。不过，最好从一个好的算法开始。我们将在硬件特定部分讨论这个问题。
“这场斗争可能并不总是最强，也不是最快的比赛，但这是打赌的方式。” - 吉卜林。
有时，针对特定问题的最佳算法不是单一的算法，而是专门针对稍微不同的输入类的算法集合。这个“polyalgorithm”可以快速检测出需要处理的输入类型，然后发送到相应的代码路径。这就是上面提到的排序包所做的：确定问题的大小并选择不同的算法。除了结合quicksort，shell排序和插入排序之外，它还会跟踪快速排序的递归深度并在必要时调用堆排序。在string与bytes包做类似的事情，检测和专门处理不同的情况。与数据压缩一样，您对输入内容的了解越多，定制解决方案就越好。即使优化并不总是适用，通过确定使用和执行不同的逻辑是安全的，使代码复杂化可能是值得的。
这也适用于你的算法需要解决的子问题。例如，能够使用基数排序可以对性能产生重大影响，如果只需要部分排序，则可以使用快速选择。
有时候，而不是专门针对您的特定任务，最好的方法是将其抽象为研究人员已经充分研究的更一般的问题空间。然后，您可以将更一般的解决方案应用于您的特定问题。将你的问题映射到已经有很好研究实现的领域可能是一个重大的胜利。
了解你的每种输入尺寸可能在生产中有多大。
你的基准测试必须使用适当大小的输入。正如我们所看到的，不同的算法在不同的输入大小下都有意义。如果你的预期输入范围<100，那么你的基准应该反映这一点。否则，选择最适合n = 10 ^ 6的算法可能不是最快的。
能够生成有代表性的测试数据。不同的数据分布会在你的算法中引发不同的行为:想想经典的“数据排序时快速排序为O(n ^ 2)”示例。类似地，对于均匀的随机数据，插值搜索是O(log log n)，但是O(n)最差的情况。知道你的输入是什么样子是代表性基准和选择最佳算法的关键。如果你用来测试的数据不能代表实际工作负载，那么你可以轻松完成针对某个特定数据集的优化，“过度配置”你的代码以便使用一组特定的输入进行最佳工作。
这也意味着你的基准数据需要代表真实世界。如果重复的请求非常少见，保留它们比重新计算它们更昂贵。如果你的基准数据仅包含相同的重复请求，则缓存将提供不准确的性能视图。
另请注意，一旦部署到生产环境并且在40核心服务器上达到25万次/秒，笔记本电脑上可能看不到的一些问题就可以看到。
编写好的基准测试可能很困难。 TODO：microbenchmarks显示速度减慢但宏观（现实世界）性能提高的情况。
程序调优曾经是一种艺术形式，但编译器变得更好。所以现在事实证明，编译器可以比复杂的代码更好地直接优化代码。Go编译器在匹配gcc和clang方面还有很长的路要走，但这确实意味着在调整时需要小心，特别是在升级Go版本时不要变得更糟。一旦编译器得到改进，肯定会出现一些针对缺少特定编译器优化工作的调整。
TODO：https : //github.com/golang/go/commit/9eb219480e8de08d380ee052b7bff293856955f8）
如果你正在解决特定的运行时或编译器代码生成问题，请始终使用指向上游问题的链接记录你的更改。这可以让你在bug修复后快速重新访问你的优化。
打击基于民间传说的崇拜“性能提示”的诱惑，甚至是从你自己的经验中过度概括。每个性能缺陷都需要根据自身的优点加以处理。即使之前已经有效，确保配置文件确保修复仍然适用。你以前的工作可以指导你，但不要盲目应用以前的优化。
程序调优是一个迭代过程。继续重新访问你的代码并查看可以进行哪些更改。确保你在每一步都取得进展。经常有一项改进可以使其他人获得成功。(现在我没有做A，我可以通过做C来简化B)。这意味着你需要继续观察整个图片，而不是沉迷于一小组线。
一旦你确定了正确的算法，程序调优就是改进算法实现的过程。在Big-O表示法中，这是减少与程序相关的常量的过程。
所有的节目调整都要么让速度变慢，要么减慢速度。算法变化也属于这些类别，但我们将看到较小的变化。你的具体做法随技术变化而变化。
做一个缓慢的事情可能会用更快的散列函数替换SHA1或者hash/fnv1。少做一次缓慢的事情可能会节省一个大文件的哈希计算结果，因此你不必多次执行该操作。
保留意见。如果不需要做什么，请解释原因。通常，在优化算法时，你会发现在某些情况下不需要执行的步骤。记录它们。其他人可能会认为这是一个错误，需要放回去。
空程序立刻给出了错误的答案。 如果你不必是正确的，那么很快就会很快。
“正确性”可以取决于问题。启发式算法大多数情况下是正确的，大部分时间都可以很快，而且猜测和改进的算法可以让您在达到可接受的限制时停下来。
缓存常见情况：
我已经完成了一个网络跟踪实验，表明即使是最佳的缓存也不值得。你的预期命中率很重要。你需要将比率导出到你的监控堆栈。不断变化的比例将显示流量的变化。然后是重新访问缓存大小或过期策略的时候了。
程序调优：
程序调优是以小步骤迭代改进程序的艺术。Egon Elbre列出了他的程序：
调整可以采取多种形式。
许多针对调优的民间传说性能提示依赖于对编译器的优化不足，并鼓励程序员手动完成这些转换。编译器一直在使用更新，而不是用15年的时间乘以或除以2的幂 - 现在没有人应该亲自去做。类似地，提升循环中的不变计算，基本循环展开，常见子表达式消除等等都是由gcc和clang等自动完成的。Go的编译器完成了其中的许多工作，并继续改进。一如往常，在提交新版本之前进行基准测试。
编译器无法做到的转换依赖于你了解有关算法，输入数据，系统中的不变量以及可以做出的其他假设等事情，并将该隐式知识分解为删除或更改数据结构中的步骤。
每个优化都会对你的数据进行假设。这些必须记录下来，甚至更好地进行测试。这些假设将会在你的程序崩溃，放慢速度，或随着系统发展而开始返回错误数据的地方。
程序调整改进是累积的。5倍3％的改善是15％的改善。进行优化时，值得考虑预期的性能改进。用更快的替换哈希函数是一个不断改进的因素。
了解你的要求和可以改变的地方可以提高性能。在#performance Gophers Slack频道中呈现的一个问题是用于为字符串键/值对映射创建唯一标识的花的数量。最初的解决方案是提取键，对它们进行排序，并将结果字符串传递给散列函数。我们提出的改进解决方案是在键/值添加到地图时对其进行单独散列处理，然后将所有这些散列在一起以创建标识符。
这是一个专业化的例子。
假设我们正在处理一天中的大量日志文件，并且每行都以时间戳开始。
Sun 4 Mar 2018 14:35:09 PST <...........................> 对于每行，我们调用time.Parse()把它变成一个格式。如果性能分析显示我们time.Parse()是瓶颈，那么我们有几种方法可以加快速度。
最简单的方法是保留先前看到的时间戳和相关历元的单项缓存。只要我们的日志文件在一秒钟内有多行，这将是一场胜利。对于1000万行日志文件的情况，这种策略将昂贵的呼叫数量time.Parse()从10,000,000减少到86400 - 每个独立的秒钟一个。
TODO：单项缓存的代码示例
我们可以做更多吗？因为我们确切知道时间戳的格式， 并且它们都在一天内完成，所以我们可以编写自定义时间解析逻辑，将其考虑在内。我们可以计算午夜的时代，然后从时间戳字符串中提取小时，分钟和秒 - 它们都将在字符串中处于固定偏移量 - 并执行一些整数运算。
TODO：字符串偏移版本的代码示例
在我的基准测试中，这将解析时间从275ns / op减少到5ns / op。（当然，即使在275 ns / op下，你也更有可能在I / O上被阻塞，而不是在时间解析上被CPU阻塞。）
一般算法很慢，因为它必须处理更多的案例。你的算法可以更快，因为你更了解你的问题。但是代码与您需要的密切关系更紧密。如果时间格式发生变化，更新更加困难。
优化是专业化的，专用代码比通用代码更易于改变。
对于大多数情况，标准库实现需要“足够快”。如果你有更高的性能需求，你可能需要专门的实现。
定期进行配置文件以确保跟踪系统的性能特征，并准备随着流量变化重新优化。了解你的系统的极限，并有好的指标，让你预测什么时候你会达到这些限制。
当你的应用程序的使用发生更改时，不同的部分可能会成为热点。重温先前的优化并决定它们是否仍然值得，并在可能的情况下恢复为更易读的代码。我有一个系统，我使用一组复杂的mmap优化了启动时间，反映了不安全性。一旦我们改变了系统的部署方式，这个代码就不再需要了，我用更可读的常规文件操作取代了它。
优化工作流程摘要 所有优化都应遵循以下步骤：
一般适用于源代码的技术
你不止一次支付内存分配。第一个显然是你分配它的时候。但是，每次垃圾收集运行时，你也要付出代价。
减少回收再利用。 - @bboreham
特定于运行代码的体系结构的技术
counts[i & 1] ++并不总是更快，但通常更难以阅读 TODO：ASCII类计数示例和基准
你需要一个互斥体来保护共享的可变状态。如果你有很多的互斥量争用，你需要减少共享，或者减少mutable。减少共享的两种方法是1）分割锁或2）独立处理，然后合并。为了减少mutable：好吧，让你的数据结构是只读的。你还可以通过减少关键部分来缩短数据共享的时间 - 尽可能少地锁定锁定。有时候RWMutex就足够了，但是请注意，它们比较慢，但是它们允许多个读者进入。
如果你正在分解锁，请注意共享缓存行。您需要填充以避免缓存行拥有权在处理器之间弹跳。
var stripe [8]struct{ sync.Mutex; _ [7]uint64 } //互斥量为64位; 填充填充缓存行的其余部分
大多数情况下，你不会看到一个CPU限制的例程。这是一个简单的例子。如果你有优化服务，则需要查看整个系统。监测。指标。随着时间的推移记录很多事情，这样你可以看到它们变得更糟，所以你可以看到你的更改对生产的影响。
tip.golang.org/doc/diagnostics.html
实施论文的提示:( algorithm另请参阅data structure）
类似地，对比更复杂的红黑或AVL树也可以找到对照或者跳过列表。在现代硬件上，“较慢”的算法可能足够快，甚至更快。
最快的算法经常可以被几乎一样快速且容易理解的算法取代。
道格拉斯W.琼斯，爱荷华大学
增加的复杂性必须足以使得回报实际上值得。另一个例子是缓存驱逐算法。不同的算法可以具有高得多的复杂度，仅命中率的小改进。当然，您可能无法在测试之前进行测试，直到您有一个可行的实施并将其整合到您的程序中。
有时候这篇论文会有图表，但很像只发布正面结果的趋势，但这些倾向往往会偏向于表示新算法的优点。
通常，早期的论文会更容易理解，并且必须具有更简单的算法。
并非所有的文件都很好。
查看论文写入的上下文。确定有关硬件的假设：磁盘空间，内存使用情况等。一些较旧的论文在70年代或80年代进行了合理的不同折衷，但不一定适用于您的使用案例。例如，他们认为什么是“合理的”内存与磁盘使用的权衡。内存大小现在增加了数量级，并且SSD改变了使用磁盘的延迟惩罚。同样，一些流媒体算法是为路由器硬件而设计的，这可能会使转换成软件变得非常痛苦。
确保算法对数据保持的假设。
这将需要一些挖掘。你可能不想实现你找到的第一篇论文。
https://blizzard.cs.uwaterloo.ca/keshav/home/Papers/data/07/paper-reading.pdf
一个良好的理解可能会让你从论文中提取关键的想法，并且可能将这个想法应用于你的问题，这可能比重新实现整个事情更简单。
还要注意GitHub上的其他实现：它们可能与您的bug相同（或不同）。
有关此主题的其他资源：
湘公网安备 43102202000103号