尽管在这个 Blog 上有三个月的空白，但在实际生活中却并非如此。相反，这三个月经过的事情貌似比上一年加起来还多。当然，过去的已经过去，新的生活才刚刚开始～

本年度剩余时间的打算：

1. 完善一下现有的 PHP 反编译器，完成难度 4；
2. 写一款较为完善的 PHP 加密工具，完成难度 5；
3. 使用 Delphi 写一款 PHP 的 IDE，完成难度 7；
4. 找一份合适的工作，完成难度 8；
5. 找一个合适的MM，完成难度 10。：（

根据 Sebastian Bergmann 提供的基准测试数据表明，在各个 PHP 版本之间，5.1 和 5.2 的速度明显要快于 5.0 和 4.4，前者的速度几乎是后者的两倍（执行时间越短越好）。无论是 GCC 还是 ICC ，打开优化(/On)后的性能也明显比不打开优化（/O0）高出一大截，也几乎是两倍的关系，而且在 PHP 5.1/5.2 身上效果更为突出。但具体的优化（O1、O2、O3、Os）之间性能差别不大，令人意外的是 PHP 5.1/5.2 的 Os 优化反倒比 On 等差了很多。

在编译器之间的比较方面，GCC3 和 GCC4 的性能并无太大差别，ICC9 的表现较 GCC 大约有 10% 左右的提升。

如何看待这些测试结果呢？

整体来看，似乎是 PHP 5.1/5.2 的速度完全占据了压倒性的优势。并且 5.1.6 的速度还要比 5.2.0 快那么一点点。这主要应归功于自 PHP 5.1 开始 Zend Engine 的虚拟机采用了新的基于 Call 调度而不是老式的那种基于 Switch 调度的执行器。这种改变主要是为了充分利用现代 CPU 已经普遍具有的超大缓存和多级流水线分支预测特性。目前来看效果是十分明显的。

PHP 5.1.6 和 5.2.0 的虚拟机基本上是相同的，既然这样，那为什么 5.1.6 会比 5.2.0 略快呢？原因就是其采用的内存管理器不同。在 PHP 5.2.0 中，Zend Engine 采用了一种类似内存池技术来管理内存。内存管理器通过 emalloc()/efree() 等接管对实际内存的申请和释放工作，在通过 efree() 释放时并不真正释放内存，而是将其放入到一个链表中，打上一个“可用”标记，下次再通过 emalloc() 申请时就先在这个“可用内存链表”检索，若有可用内存（即打有“可用”标记的内存）则直接返回，否则再真正申请。显然这一工作要比 5.1.0 之前那种仅仅是 molloc/free() 简单封装的 emalloc()/efree() 做的工作要多。因此速度慢些也就情有可原了。但是这种方法主要是用以改善 PHP 在高负载下表现的（具体优点请 google “内存池”），在这样的基准测试中是完全看不到这样做的好处的。

因此，我们应该这样看待这次的基准测试：基准测试（Benchmark）只是一种“基准的测试”。它仅能展示了在某种情况下 PHP 语言特性的表现，它无法展示 PHP 在各种真实世界中表现。它可以给我们做一份很重要的参考，但你应该根据实际情况合理采用。比如说 ICC 的表现要强于 GCC，但 PHP 开发团队采用的编译条件基本上都是 GCC + O2 + i386 ，那么在 ICC 中、或者在GCC 的 O3、-pentium_pro 的稳定性就还有待于时间的检验。此外若你负载压力较大或安全性要求较高，那 5.2 就比 5.1 相对要好。如果你的系统在 PHP4 上表现很好，而且没有太大负载，那就完全没有必要移植到 PHP5。当然，若果是全新的开发和部署，我还是向您推荐性能与稳定俱佳的 PHP 5.2.0。:)

于是，我尽我所能地做得坚强，努力在第 N 天只以 1/N 的概率想起她，那样，最终会有一天我能不再想她。

然而，即便如此，在未来我想起她的次数还是趋向于无穷大。