事实上你应该优化，但要在正确的地方，有足够的理由。我待会儿再聊这个。
我最近和在 Badgerpunch Games 的几位朋友一起发布了一个小的以XNA为基础的游戏，而且通过论坛和Twitter与这个独立的游戏开发组织保持密切的联系。游戏开发者十分在意性能问题，而且这很必要。没有人想要一个运行不畅的游戏。因为这些对性能的担忧，出现了很多关于优化技巧的提示和论文，都围绕着如何能实际有效的缓解性能问题。大多数的技巧提示和文章都提供了有价值的信息、有相应的用处，但你会发现很少有文章能触碰到性能优化上的主要问题：什么时候不该优化，为什么。
优化就是这样的事：你的程序可以一直优化下去，但工时上的开销和取得的效果的对比会很快让你陷入困境。我记起了九十年代早期在 Amiga Demo 公司的一幕。我大概花了半年的时间去优化那个3D旋转的汇编程序片段。最终我觉得该优化的几乎都优化了。起初几周我努力减少CPU的指令循环，获得了惊人的减幅！但随后的数月里，我几乎没法再进一步的压缩，最终只得放弃 … 我这段程序超级的快，可是，其他程序员的3D图形跑的比我还要快，我无法理解，这怎么可能？
直到数年后我在大学里学了矩阵后我才明白其中的奥秘。我的程序里每个3D坐标用9次乘法，这是一个没有优化的矩阵算法，它可以被压缩成6次乘和两个加法，这样每个坐标点可以节省数百次的CPU指令循环 … 太郁闷了！
这个故事的寓意？你可以优化你的程序，让它像星星一样闪亮，但如果有人有更好的算法，让同样的程序跑的更快，你还是很失败。
你很失败吗？只是在有意义的时候才能这样说。在上面的性能优化的故事里，3D旋转效果是被限制在一个16位的机器上的，这种情况下最快的程序证明了最出色的程序员，这时它的意义就很大了。