这里记载的是我觉得在做优化工作时应该秉承的原则与步骤，不是具体的优化方法（优化方法google有很多）。
一提到性能优化，就会听到双引号、单引号、三等号之类的，我认为如果按着这个去做，就有点舍本逐末了。
做优化之前，先说一下我对系统设计目标的理解
- 第一位：可运行。这是最重要的，应该没有什么异议。
- 第二位：可维护。要保证一段时间以后，别人或你自己可以对这套设计进行维护。
- 第三位：性能与其它
其中，第二位与第三位的顺序肯定有人提反对意见，因为我一个朋友就提过，但一段时间后，他也同意了可维护要比性能更重要些。 这里只能说是我个人的经验，没有办法像数学公式证明那样一步步的给出证明过程。
优化顺序
这里从PHP程序本身来说下性能。
首先：良好的系统设计
我敢保证，对于Web系统，绝大多数情况下PHP本身不会成为性能瓶颈。瓶颈经常是系统设计、业务逻辑梳理有问题。 如果系统设计不合理，就算我们把所有的双引号替成单引号也无济于事。
这里举个例子，我们一个系统设计初期没有很多对cache访问进行规划，单次请求中cache访问次数过多，出现 还不如访问数据库快的情况。（因此，cache应该像关系表那样从一开始便进行精心设计）
然后：代码与脚本
这一步也比较关键，实际中经常会碰到过两类问题：
- 循环中套了sql操作。
- 脚本过多、过大。
其中第二类问题大家经常忽略。前不久我们访问一个内部服务（依赖其提供的sdk），性能怎么都提不上去。最后 我把sdk中所有的类都合并到一个文件中，性能瞬时提高了10%。这是脚本过多的问题，我们解决了，但是脚本过大的 问题我们没有解决，因为就算合并后，代码也是有几千行，在xhprof呈现的性能report里仍然是一个大大的方框。
对于脚本过大，再提个大家可能不太容易注意到的建议：把controller/action设计改成action设计， 这样可以避免超大controller的出现，从而提升部分性能。
对于单引号、双引号问题，我建议在项目中保持统一即可。要么单双分开用，要么统一双引号，这不会 成为性能的瓶颈所在。
对于三等号、双等号问题，我建议主要从程序逻辑正确性这方面来考虑如何使用。
说到脚本了，提个长久一来的疑问：smarty等有必要存在么？php的原生模板语法不是更好么？
最后：着眼PHP本身
如果系统性能还是不理想，则需要从服务器环境本身来考虑考虑了。
- 如果php version
- 部分稳定、公用的逻辑，写成PHP扩展。比如程序框架（@see yaf）、访问纯真ip数据库等。
做了这么多年web，我一直相信一点——PHP本身很难成为性能瓶颈所在。
