这些日子在看 .NET CLR 方面的书籍。由于和 Zend Engine 一样同属虚拟机运行方式，因此不可避免的就要互相比较一下，感触颇多。下面将我在这些天在看书时想到的一些对 Zend 可能有用的一些想法写一下，欢迎大家探讨。
Zend Engine 将 PHP 的执行机制划分为编译和执行无疑是革命性的举动。但现在看来，这似乎还未完全将这个思想贯彻到底。当前的 Zend Engine 虽然把编译和执行分成两个步骤来做，但这两个步骤对一个普通 PHP 脚本文件来说确是连续的。换句话说，当 web 服务器开始处理一个 PHP 脚本请求后，它将不得不每次都进行编译和执行两个步骤。很明显，对于一个开发完成不再进行经常性的修改的 PHP 脚本来说，这将是巨大的性能损失。
PHP6 或许会解决这个问题，但我估计和目前 eAccelerator 的解决方案类似。当脚本第一次运行后，以某种方式保存编译后脚本，在我们规定的缓存有效时间内，当第二次运行该脚本时就不在进行重复性的编译工作，而是直接调用前面保存的编译后文件，大大提高了程序性能。
但是，这是否就足够了呢？根本不够！还需要在此基础上再大胆地迈出一步，将编译和执行完全分离！即像普通地二进制 PE 文件一样，PHP 可独立解释编译后的文件！实现方法并不复杂，我们不妨约定一个编译后文件格式，并且让其开头几个字节为“ZIC”作为该类型文件的标识（姑且让我们暂称之为 PHP/Zend 中间码形式的可执行文件，以下简称 PHP 可执行文件）。若 Zend Engine 检测到某个文件为 PHP 可执行文件，则跳过编译函数直接调用执行函数开始执行代码。
慢着，你这不是和 eAccelerator 或 Zend Optimer 一样吗？是一样，但又不一样。说一样是因为运行效果一样，说不一样那是因为编译过程可以不放在 Zend Engine 里面！这意味着什么？这意味着 Zend Engine 将成为和 Windows 一样性质的虚拟机，即执行工作我 Zend Engine 来做，编译工作交给独立的 PHP 编译器来做。由于 PHP 可执行文件格式公开，那么各个公司、团体或个人都可以来开发相应编译器。编译效率高、可执行代码性能好编译器自然就会更受到市场的追捧，你可以想像市场对这种编译器的需求。Zend 只是 PHP 编译器的实现厂商之一。当然，由于 Zend 公司在 PHP 方面的特殊地位，Zend 公司出品的 PHP 编译器无疑会具有很大的先天优势。但不管怎样，这要比只有 Zend 团队自己来做要好很多。有竞争才会有进步嘛！这就像 Micosoft 之于 .NET 的 CLR，以及众多的 C/C++ 编译器之于 C/C++。
以上仅仅是好处之一，同时也是下面我谈的改进 Zend Engine 的种种设想的基础，没有上面机制的实现，那下面的几条设想也就无从谈起。
首先，我们可以像直接书写汇编代码一样直接书写中间代码。当然，这对开发人员有很高的要求。但对于 PHP 编译器的开发商来说，确实不可缺少的。
其次，增加 #define、#ifdef、#ifndef 这样条件编译指令。最好由 PHP 官方直接增加，不得已也可以让各 PHP 编译器厂商扩展增加这样的指令。反正最后产生的 PHP 二进制代码，不怕 Zend Engine 不运行。这样做的好处也是巨大的。我们可以根据适当的编译指令编译出 PHP4 版本的代码、PHP5 版本的代码，甚至是只限于 PHP5.1 的代码，在缩减代码长度，减小对内存需求的同时也更增加了程序的运行速度。自然的，我们也可以根据需要编译出标准版或者专业版等等的代码。更可以想到的，传统程序的编译优化，开发技巧都可以大批量的应用到 PHP 开发上。
再次，这也在一定程度上保护了源代码安全，至少不需要分发源代码了。而且跟 Open Source 并不冲突，若开发人员愿意，也可以在分发程序的同时分发源代码。
最后，提供对类似在 ASP.NET 中 web.config 文件（比如 php.config、app.config.php 等）的支持。此处关于这个文件的作用我不再多讲，感兴趣的朋友可以去 google 一下关于 ASP.NET 中 web.config 的信息。
这些就是我这些天对改进 Zend Engine 的一些思考。应该说，这些东西都是非常容易实现的，而且在 Zend Encoder/Zend Optimer 身上已经实现，Zend Encoder 就是一个编译器，Zend Optimer 也是一个独立执行器！
但这并不会给 Zend 公司带来业务上的冲突。相反，这会给 Zend 公司带来更多的发展潜力。前面已经提到过，Zend 公司在 PHP 编译器方面的先天优势可以说是巨大的。这一点无庸讳言。Zend 不应该定位在“我可以实现它”的层面上，而应该定位在让大家“都能实现它”但我是“实现最好的”这个层面。通俗点说，就是先让大家都来玩，都能玩，但是只有我才我能让你们玩得最爽！
再来谈谈 Zend Studio。Zend Studio 怎么发展？简单！学 Microsoft Visual Studio！做一个真正的 IDE，集成最 Cool 的编译器，完善的项目管理机制，再加上负载测试，想想都让人流口水～ 只是有一句话憋了很久了，别再用 Java 做 IDE 了。这只是方便了 Zend Studio 的开发人员，但却没有方便 Zend Studio 的使用人员，而且还给 Java 这个竞争对手露了脸。唉，不知道 Zend 公司是怎么想的～
最后再说说 Zend Encoder，加密会降低程序性能，混淆才是王道。混淆只是一种内存指针的替换，名字对于 CPU 来说无关紧要，但这对开发人员来说却很致命。有策略得进行混淆加密，完全可以在牺牲很小性能的情况下极大的增加反编译强度。这些方面，我以后有时间会再整理一下。况且混淆后的代码完全兼容于标准的 PHP 可执行文件，因此 Zend Optimer 就不是必须要加载的了，也减轻了客户的麻烦。
先说到这，不写了，这一篇文章把我最近思考的东西全都给榨干了。行文仓促，不当之处还望各位海涵指正。
注：这也是大概半年前的文章。关于 Zend Engine 部分，我当时已经把这个想法提交给了 PHP Internal 讨论组。可惜反响不多。:( 但我至今仍坚持认为，增加 Zend Engine 直接执行中间代码的能力是无论对开发还是 PHP 的执行效率，帮助都是莫大的，而且所须进行的工作和向前兼容性的影响都是可以忽略不计的。但 Zend 公司并未采纳这个建议，相信商业因素占了大部分因素。Zend Engine 是由一个商业公司负责的，福耶？祸耶？
