已经有很多性能问题了,但是几乎所有的问题都是针对特定问题的,而且相当狭窄。几乎所有的重复建议,以避免过早优化。
假设满足如下条件:
代码已经正常工作
所选择的算法对于问题的情况已经是最佳的
代码已被测量,并且违规程序已被隔离
所有优化的尝试也将被测量,以确保它们不会让事情变得更糟
预先计算而不是重新计算:包含具有相对有限输入范围的计算的任何循环或重复调用考虑对包含有效范围内的所有值的计算结果进行查找(数组或字典)投入。然后在算法中使用简单的查找。
方面:如果实际使用的预计算值很少,这可能会使情况变得更糟,查找也可能占用大量的内存。
不要使用库方法:大多数库需要编写在各种场景下正确运行,并对参数执行空检查等。通过重新实现一个方法,您可能会去掉大量的逻辑并不适用于您正在使用它的确切情况。
下方:编写额外的代码意味着更多的表面区域的错误。
用图书馆的方法:与我自己相反,语言图书馆是由比我们更聪明的人写的; 他们做得更好,更快。不要自己实现它,除非你能更快地实现它(即:总是测量!)
好的,你正在把问题定义为看起来没有太多改进空间的地方。根据我的经验,这是相当罕见的。我试图在1993年11月的多布斯博士的文章中解释这个问题,从一个没有明显浪费的传统设计的非平凡程序开始,并通过一系列的优化,直到它的挂钟时间从48秒到1.1秒,源代码大小减少了4倍。