我来自DBA世界,表演一直是一种痴迷.我正在转向发展,我总是不断地考虑性能.
阅读SO有时似乎表现并不重要.例如,关于休眠(或任何其他ORM)的福音传教士.
作为开发人员,我什么时候需要考虑性能,何时不考虑？
一般来说,对性能或优化的迷恋是软件开发中的恶劣途径.通常,只有大约5%(或更少!)的代码对整个系统的性能有任何影响.您的主要目标,首先是作为大多数项目的软件开发人员,正在获得正确可靠的功能,当然还有系统的可维护性.然后,一旦实施并正常工作,您就可以评估性能,找出瓶颈所在,并相应地优化它们以满足您的总体目标.
一个警告:对事物采取的方法进行O(n)型评估是事先考虑的合理事情,作为原始系统设计和算法选择的一部分,等等,以确保表现将"在球场" .但除此之外,大多数在实际测量瓶颈所在之前优化事物的尝试将导致优化无关紧要的事情,并且通常会使事情变得难以维护,难以理解等.
该克努特报价("我们应该忘记小的效率,讲的时候约97%:过早的优化是所有罪恶的根源")可能适用.
当你开车时,你是否经常有意识地检查你的车与路边的接近程度？如果你有足够的驾驶经验,你就会知道它的边缘在哪里以及大致如何驾驶和停放它而不会碰到附近的东西.
编程性能的类似直觉/体验对于获得试验/错误和问题非常重要,但您不必花时间不断地仔细检查自己.
什么时候呢？
不,真的.有些应用程序永远不会有足够的用户保证数据库中的基本索引和关键关系.它们不需要调整代码的内部循环.例如,工作组大小的应用程序.
随着事物的扩展,对代码,数据访问和通信中的优化路径的需求也在增加.如果您在有限的硬件(嵌入式系统)的工作,你不在乎很多有关性能.但是有许多应用程序永远不会看到足够多的用户来制作系统资源,即使你在那里也是如此.
在这些情况下,所有额外的工作都浪费了金钱和精力.在某些情况下,您的规范明确表示您需要额外的努力.在某些情况下,它表明你永远不会.
我认为这里有两个相互矛盾的谚语.
1:过早优化是万恶之源.
2:在你跳跃之前先看看.
根据我的个人经验,情况就是在第一次编写代码时,很容易找到使用90%资源的3%代码查找魔法的可能性.这是第一个谚语相关的地方,似乎产生了很好的结果.然而,随着代码库的成熟,似乎使用90%的资源而不是3%,你突然有50%使用90%的资源.如果你想象一下水管的类比,而不是几个大的泄漏,你现在有了多个小泄漏的问题,到处都是.这使整个应用程序的性能降低,即使很难确定任何一个单独的功能.
这就是谚语2似乎相关的地方.不要依赖第一句谚语,不做任何绩效计划,制定整体计划,即使它是一个不断发展的计划.尝试制定一些可接受的性能指标并计划您的计划.考虑设计选择的后期性能影响.例如,如果需要的只是一个元组存储,那么可能会提前使用元组存储而不是数据库.从SQL数据库开始,然后更改为元组存储是非常困难的.
最重要的是,尝试优化它的简单位置,并对可能进行优化的情况做出记录.如果不这样做,随着时间的推移,程序往往会遭受一千次削减的死亡,因为功能的影响要慢5到20%,而且需要加起来并且确实会成倍增加.
引用Knuth的"过早优化......邪恶"对于编写草率和慢速代码(正确或其他)是一个不好的论据.
您需要指标进行优化.
编码时需要考虑代码.
您只需优化重要的代码子集.
如果您正在编写一个简单的表单来更新某些细节,那么可能不值得优化.
如果您正在编写谷歌搜索引擎替代品,并且您希望拥有大量流量,那么您可以找到一种尽可能快地进行搜索的方法.
您只需要优化重要的代码,并且程序中有很多代码用于执行一次性事务或很少发生的事件.
鉴于我们满足上述1,2和3:
在进行任何性能测试和优化之前,等待应用程序完成90%是没有意义的.性能通常是不成功的非功能性要求.您需要识别并记下其中一些不成文的要求并将其提交给它们.
如果您需要进行架构或其他重大更改,那么完成90%也可能为时已晚.编写的代码越多,改变事物就越难,只要考虑到需要考虑的代码.您需要不断确保您的应用程序能够在需要的时间和地点执行.
再说一次,如果你有完善的单元测试,你应该能够将性能测试作为这些测试的一部分.
至少我的先令是2先令.
京公网安备 11010802040832号 | 京ICP备19059560号-6 