在以下两个方面,可能需要优化速度:
哪里是最适合开始优化的地方?
通常,被称为最常用的代码的执行时间已经很低了。您是优化较慢、较少调用的区域,还是花时间优化速度更快、使用率更高的区域?
发布于 2011-02-22 18:56:04
你应该忽略小效率95%的时间。首先,让它正确工作,然后分析.
您对高级算法的选择可能会对软件的总体性能产生巨大影响,以至于一个看似微不足道的选择可能意味着等待程序启动20分钟与拥有一个快速、响应的UI之间的差别。
例如,在3D游戏中:如果您从场景图中简单的对象平面列表开始,您将看到相对较少的对象的性能极差;但是如果您实现了卷层次结构(如八叉树或BVH),并在绘图时对树的部分进行裁剪,您将看到极大的性能提升。
当你的设计看起来正确的时候,你就可以继续.
较低层次的算法也会产生显著的影响。例如,在进行图像处理时,如果您按错误的顺序读取图像,当您遇到常量的L2缓存丢失时,您将经历大量的慢速下降;重新排序您的操作可能意味着性能会提高十倍。
在这一点上,分析并找出程序大部分时间被花费的地方,并找到消除它的方法。
发布于 2011-02-22 19:31:54
首先,运行一个分析器来找出您的代码花在哪里的时间。
然后,看看这些地方,看看哪些地方看起来容易优化。
寻找最简单的解决办法,以获得最大的收益第一(去低挂水果)。确切地说,不要太担心它有多重要。如果容易的话,就把它修好。会加起来的。25个简单的修复可能比一个大的修复更快,它们的累积效应可能更大。如果很难的话,做个笔记或者提交一份错误报告,这样你以后就可以优先处理它了。在这一点上不要太担心“大”或“小”,只需这样做,直到你开始使用非常少的时间的函数。一旦你这样做了,你就应该更好地知道你发现的其他问题中哪一个会以最少的时间投资获得最大的收益。
不要忘记在修复之后进行分析,作为一种回归测试,以验证您的性能更改是否达到了您希望的效果。此外,不要忘记运行您的回归套件,以确保没有功能被破坏。有时糟糕的性能会显示工作环境,而试图修复性能会破坏功能。
无法优化但花费大量时间的小函数可能仍然是优化位置的提示。为什么这个函数会被如此频繁的调用?是否有一个函数调用这个小函数而不需要使用它?是重复工作,还是做不必要的工作?查找堆栈被调用的时间,直到您确信它应该经常被调用为止,并查看是否找到了一个效率较低的较大函数。
编辑以添加:由于您有需要很长时间的特定功能,所以尝试执行上面的步骤,只运行该特定函数10次左右。
发布于 2011-02-22 18:47:26
怎么说呢。这实际上取决于tha代码正在做什么。运行一个性能测试,获取一个性能概要文件,并查看在各个领域实际花费了多少时间。你的概括是..。概括,它因项目而异。
例如,调用最多的代码可能只是登录到文件或控制台。如果已经有一两行代码无法简化,那么优化这一点就没有多大意义了,而且可能任何对这样的代码进行优化的努力都可能不值得实际编写代码。最小的代码可能是在某个极其复杂的函数中使用的一些超大规模的查询。函数在整个执行过程中可能只被调用100次(简单日志语句为10000次),但是如果它运行的每一次调用都需要20秒,那么优化应该从这里开始吗?或者相反,大查询是调用最多的,而日志语句每100个查询只调用一个.
我通常不会担心这类事情(直到我需要进行性能调优),除非我提前知道了将要发生的事情。
https://softwareengineering.stackexchange.com/questions/50631
复制相似问题