没事儿别优化!

事实上你应该优化,但要在正确的地方,有足够的理由。我待会儿再聊这个。

我最近和在 Badgerpunch Games 的几位朋友一起发布了一个小的以XNA为基础的游戏,而且通过论坛和Twitter与这个独立的游戏开发组织保持密切的联系。游戏开发者十分在意性能问题,而且这很必要。没有人想要一个运行不畅的游戏。因为这些对性能的担忧,出现了很多关于优化技巧的提示和论文,都围绕着如何能实际有效的缓解性能问题。大多数的技巧提示和文章都提供了有价值的信息、有相应的用处,但你会发现很少有文章能触碰到性能优化上的主要问题:什么时候不该优化,为什么。

优化就是这样的事:你的程序可以一直优化下去,但工时上的开销和取得的效果的对比会很快让你陷入困境。我记起了九十年代早期在 Amiga Demo 公司的一幕。我大概花了半年的时间去优化那个3D旋转的汇编程序片段。最终我觉得该优化的几乎都优化了。起初几周我努力减少CPU的指令循环,获得了惊人的减幅!但随后的数月里,我几乎没法再进一步的压缩,最终只得放弃 … 我这段程序超级的快,可是,其他程序员的3D图形跑的比我还要快,我无法理解,这怎么可能?

直到数年后我在大学里学了矩阵后我才明白其中的奥秘。我的程序里每个3D坐标用9次乘法,这是一个没有优化的矩阵算法,它可以被压缩成6次乘和两个加法,这样每个坐标点可以节省数百次的CPU指令循环 … 太郁闷了!

这个故事的寓意?你可以优化你的程序,让它像星星一样闪亮,但如果有人有更好的算法,让同样的程序跑的更快,你还是很失败。

你很失败吗?只是在有意义的时候才能这样说。在上面的性能优化的故事里,3D旋转效果是被限制在一个16位的机器上的,这种情况下最快的程序证明了最出色的程序员,这时它的意义就很大了。

阅读更多

没有更多推荐了,返回首页