我来自DBA领域,性能一直是我的追求。现在我转向开发行业,我一直在思考性能问题,时刻关注。
有时在Stack Overflow上阅读,似乎性能并不重要。例如对于Hibernate(或任何其他ORM)的传教士。
作为开发者,什么情况下我需要考虑性能,什么情况下又不需要呢?
我来自DBA领域,性能一直是我的追求。现在我转向开发行业,我一直在思考性能问题,时刻关注。
有时在Stack Overflow上阅读,似乎性能并不重要。例如对于Hibernate(或任何其他ORM)的传教士。
作为开发者,什么情况下我需要考虑性能,什么情况下又不需要呢?
总的来说,在软件开发中过于关注性能或优化往往会导致很多问题。通常情况下,你的代码只有大约5%(甚至更少!)对整个系统的性能产生影响。在绝大部分项目中,作为一名软件开发人员,你的首要目标是实现正确可靠的功能,当然还要考虑系统的可维护性。然后,一旦实现并正常工作,就可以评估性能,找出瓶颈所在,并进行相应的优化以达到整体目标。
一个例外:在最初的系统设计和算法选择等方面,进行类似O(n)类型的评估是合理的考虑,仅仅是为了确保性能可以达到预期水平。但除此之外,在实际测量瓶颈所在之前,大多数尝试提前优化的行为都是优化无关紧要的事情,通常会导致代码难以维护、难以理解等问题。
这句Knuth的名言(“我们应该忘记小的效率问题,大约有97%的时间:过早优化是万恶之源。”)可能适用于此。
当你开车时,你是否会经常有意识地检查你的车离路缘有多近?如果你有足够的驾车经验,你就会知道它的边缘在哪里,大致上如何驾驶和停车,而不会碰到附近的障碍物。
类似的编程性能直觉/经验通过试错和提问获得是很重要的,但你不应该花费大量的时间去反复检查。
何时需要优化?
不开玩笑。有些应用程序永远不会有足够的用户来证明数据库中的基本索引和关键关系之外还需要更多。它们不需要调整代码内部循环。例如,小型团队应用程序。
随着事物的扩大,对于代码、数据访问和通信的优化路径需求也随之增加。如果您在有限的硬件(嵌入式系统)上工作,您非常关心性能。但是,有许多应用程序永远不会看到足够的用户,使系统资源甚至注意到您的存在。
在这些情况下,所有额外的工作都是浪费的金钱和精力。在某些情况下,您的规格说明清楚地表明您需要额外的努力。在某些情况下,它清楚地表明您永远不会需要。
我曾经有一个阶段,对性能非常担心。我花了很多时间来提高性能,结果我的代码从未真正进步过。不要养成这种习惯 :-)
先编写代码,然后再进行优化,不要同时进行。
性能不是项目结束时可以随意添加的东西。
架构优化。应用程序的整体结构是效率低下的根源吗?
算法优化:你是否使用了正确的数据结构?你是否以正确的方式访问它们?你的应用程序大部分时间是在写入还是读取?针对这个问题进行优化。
最后的选择。微调优化。简化热循环,或展开一些循环。Duff's Device。除非你确定其他两个级别无法再进一步改善,并且仍然没有达到性能目标,否则不要在这个级别上进行优化。这种优化可能会导致程序出现问题,使应用程序更难扩展,更脆弱,因此除非你真的必须这样做,否则不要这样做。