何时/如何优化通用代码？

Question

在编写应用程序代码时，人们普遍认为过早的微 - 优化是邪恶的，并且首先进行概要分析是必不可少的，并且关于要进行多少（如果有的话）更高级别优化的问题存在争议在前面。但是，我没有看到任何关于何时/如何优化通用代码的指南，这些通用代码将成为库或框架的一部分，您将永远不知道将来如何使用您的代码。这有什么指导方针？过早的微优化仍然是邪恶的吗？如何将性能与其他设计目标相平衡，例如易用性，易于证明正确性，易于实现和灵活性？

Answer 1

我认为优化必须落后于其他设计目标，例如易用性，易于证明正确性，易于实施和灵活性。

尝试使用良好实践智能编写代码并避免明显的陷阱。不过，在使用分析器和实际用例进行优化之前，请不要进行优化。

您仍会遇到一些您从未想过的用例，但如果您从未想过它们，则无法对其进行优化。

精心设计的框架通常也会合理执行。

Answer 2

“如何将性能与其他设计目标相平衡......？”

1. 让它发挥作用。

2. 优化它，直至无法进一步优化。

请注意订单。避免过早优化意味着在工作之后对其进行优化。

优化仍然非常非常重要。过早优化并不意味着没有优化。它意味着在工作后进行优化。

Answer 3

我最近听到一个有趣且非常有启发性的讨论关于播客上的着名knuth引用（认为它是深刻的字节），我将尝试总结：

每个人都知道这句名言：过早优化是万恶之源。 然而，这只是它的一半。完整的引用是：

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil

仔细看看 - 大约97％的时间说 该声明的另一面是约3％的时间，“小”效率是至关重要的。

我的显示器显示约50行代码。从统计上来说，每个屏幕上至少有1-2行代码会包含对性能敏感的内容！遵循“现在就做，以后进行优化”的常识，如果您认为在每个屏幕上存在可能的性能问题，那么这似乎不是一个狡猾的计划。

恕我直言，你应该一直在考虑表现。在通过分析/测试证明之前，你不应该花费大量的精力或牺牲它的可维护性，但你绝对应该把它放在脑海中。

我个人将此应用于这样的通用代码：
你一定会在某个地方有一些代码，当你写它时你会认为“这会很慢”，或者“这是一个愚蠢的算法，但它现在并不重要，所以我稍后会修复它。”当你在共享库中并且你无法断言方法A只会被调用5个项目时，你应该进入并清理所有这些内容。

一旦你把这些东西整理好了，我就不会再费劲了。也许在你的单元测试中运行探查器以确保没有任何愚蠢的东西偷偷摸摸，但是否则等待来自你的库的消费者的反馈。

Answer 4

我的经验法则是：

不优化

完整的规则实际上是：

如果您没有指标，请不要优化

这意味着如果您没有测量性能并生成具体指标，则不应该采取任何措施来使代码更好地运行。

毕竟：没有指标，你怎么知道要优化什么？

一旦你进行了一些分析，你可能会对系统性能瓶颈的位置感到惊讶......根据我的经验，相对较小的变化通常会产生巨大的影响。

Answer 5

你是对的并不总是清楚你的时间最好的降压在哪里。您最好的选择是成为您框架的用户以及其设计师。

在非平凡的应用程序中使用您自己的框架，尝试运用所有功能。你使用的越多，你就会发现哪些是你最需要的东西。

此外，请尽可能频繁地获取其他用户的反馈和建议。您将不可避免地发现其他人希望与您永远不会想到的框架有关。

Answer 6

我认为最好的方法是为您的框架提供一套非常好的用例。只有这样，您才能清楚地了解其性能是否足以满足其预期用途。

当然，你永远不会知道某人将来会如何使用你的框架（在我职业生涯的早期，它从未让我惊讶于用户使用我的软件的创造性方式 - 方式我从来没有设想过！）但是考虑到你认为它将如何被使用应该会让你在那里大部分时间。