问何时/如何优化泛型代码？

EN

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

1. 让它工作。
2. 优化它直到它不能进一步优化。

注意顺序。避免过早优化意味着在其工作后对其进行优化。

优化仍然非常非常重要。过早优化并不意味着没有优化。这意味着优化后，它的工作。

我要说的是，优化必须放在其他设计目标的次要位置，例如易用性、演示正确性、易于实现和灵活性。

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

您仍然会遇到一些您从未想过的用例，但是如果您从未想过它们，您就无法为它们进行优化。

一个设计良好的框架通常也是一个性能合理的框架。

最近，我在一个播客上听到了关于著名的knuth引语的有趣和非常有启发性的讨论(认为这是深度炒股字节)，我将尝试总结如下：

众所周知，过早优化是万恶之源。

然而，这只是其中的一半。全文如下：

。

仔细看看这个--说出大约97%的时间。

这句话的另一面是大约3%的时间，“小”效率是至关重要的。

我的显示器显示了大约50行代码。统计上，每个屏幕上至少有1-2行代码将包含一些性能敏感的内容！按照“现在就做，以后再优化”这一常识，当你认为每个屏幕上都有可能出现性能问题时，似乎并不是那么狡猾的计划。

IMHO你应该一直考虑性能。在通过分析/测试证明之前，您不应该为它花费大量的精力或牺牲可维护性，但是您肯定会把它放在脑后。

我会亲自将这个应用于像这样的通用代码：

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

一旦你把这些事情解决了，我就不会再多说下去了。也许可以在单元测试中运行分析器，以确保没有什么愚蠢的东西潜入其中，但否则，请等待库的使用者的反馈。