辛德蕾拉|写了多年软件，我在软件性能上学到的 4 点教训( 二 ) 12345678

我创建 livegrep 来用在正则表达式上，这在很大程度上是一个有趣的技术挑战——理论上，对于 Livegrep 的许多使用场景来说，语法或语义感知搜索听起来更好一些。但是，我从未见过像 livegrep 一样快的语法感知工具，而且我逐渐体会到 livegrep 的交互功能引出了它额外的功能，因为它使迭代和优化搜索变得容易。而且，大多数工程师已经对正则表达式有所了解，并且能以交互方式进行实验，实时浏览和查看结果，相对于使用复杂的查询语法来实现搜索， livegrep 显得更加用户友好，方便使用。
三、性能需要贯穿项目整个生命周期在项目的整个生命周期中，追求性能需要付出一定的努力。如今，不用担心性能问题这个观点越来越流行，尤其是在项目初期。我们经常听到这些论调：

“过早的优化是万恶之源”
“先运行，再纠正，后调优”
“CPU 的时间总是比工程师的时间廉价”

我们会从那些认为 Ruby 或 Python“ 足够快”的人那里听到类似的观点。这个观点要表达的似乎是性能仅仅是最后才要考虑的事情，有效的代码才最关键。
我了解到的普遍流行的哲学观点似乎是，首先应该以最快的方式编写出应用程序，只有在程序正常工作后，再转向利用分析器并开始逐个优化热点代码，甚至最后可能将某个组件使用更快的编程语言或技术进行重构。
这确实是一个不错的并被普遍默认接受的建议，但也了解到，认识到这些观点的局限性，并在项目开始时能够寻求其他的实现形式确实很重要。特别是，我开始相信“功能优先，性能让步”模型很少会产出真正高性能的软件（并且如上所述，我认为真正快速的软件是一个值得追求的目标）。我总结了上面的方法论无效的两个主要原因：
1. 软件架构会直接影响性能
系统的基本架构（高级结构、数据流和组织形式）通常会对性能产生长远影响。正如之前讨论的那样，我们在Sorbet 中所采取的一个设计决策是仅在方法内执行局部类型推断。这一决定对类型系统和用户体验产生了影响，但同时也使Sorbet 大大简化、更快并且更易于并行化和增量扩展。
提前进行架构设计，后续的维护成本会降低，否则，后期如有修改，成本陡增。 Flow 团队仍处在持续多年的重构计划当中，他们的目标是将Flow 和Facebook 的代码迁移到本地化模型中（我想明确一点，我并不是在批评Flow 团队的选择。他们的工具在Facebook 内部和外部都非常成功，而且他们做出的决定在当时来看是没有问题的。他们在博客中讨论过这个问题，我很欣赏他们能对外公开透明。不过，我发现这个案例在一定程度上可以说明早期架构决策会对现在产生一定的影响）。
如果你要构建真正的高性能软件，那么在制定早期设计和体系架构决策时需要牢记性能因素影响，以免日后陷入非常尴尬的境地。
2. 优化性能不能只关注热点代码
像大多数编译器和类型检查器一样， Sorbet 也没有什么热点代码。 CPU 时间在软件代码的不同功能部分被相对均匀的分配和执行。这种均匀分散执行从根本上意味着，不可能对一个检查器通过优化热点代码的形式来提升性能，因为几乎没有热点代码可以进一步优化。
相反，我在上一篇文章中讨论的许多技术，例如缓存优化的数据结构或用 C ++ 重构实现关键模块，实质上会使类型检查器中的每一行代码都执行得更快，从而使整个应用的性能得到提升。
我最喜欢的性能提升案例之一，就是 SQLite 3.8.7 版本比以前的版本性能提升 50％，所有这些都是通过大量累加的微小性能改进而实现的，其中每个优化获得的性能增加不到 1％。这个例子提到，每个优化对整体代码的优化提升微不足道，即使是这样，性能优化随着微小性能改进的累积可以逐步放大。尽管，最后 SQLite 开发人员是在产品成熟之际进行了这个优化工作，但是，如果能在产品早期进行 1% 的优化，后续的优化工作也会简单很多。