关于 Zend Framework 和国产 FXXX 在类加载性能上的测试

 之前,FXXX 的主要开发者 L 兄曾经在 phpchina 上同我做过一些讨论。当然讨论的结果似乎不能令人满意。FXXX 对于我一直所诟病的数据库支持对于 L 兄来说似乎不是什么大的问题。而 Zend Framework 对于他来说似乎也是一直拥有效率黑洞,以及大而不精等诸多糟粕。Zend Framework 即将成为 PEAR2 是 L 兄一个比较精辟的形容。

项目中最初推翻 FXXX 转而使用 Zend Framework 主要是由于 Orcale 的支持问题。但是这个问题似乎是 FXXX 的软肋,不能碰,一碰就招致狂风暴雨般的质问。当然,质问的内容不是框架的数据库支持。而是触碰这个软肋的人的技术水平问题。而 Zend Framework 的性能黑洞,也让我带着意思疑虑。Zend Framework 的性能是否真的不可调和,这个框架是否真的又臃肿,又庞大?带着这个问题,我做了以下试验:

试验内容:为了检测 Zend Framework 的性能到底如何,我必须选择一个参照对象。很遗憾,优秀的 FXXX 被选中了。因为这个性能的疑虑正是 L 兄带给我的,所以………….解铃还需系铃人。

那么对两个框架所有的部分都进行测试,似乎不太可能。这绝对是超出我能力范围的。那么我选择了 Loader 作为测试的内容。两个框架都有各自的加载类的方法。而这个方法又是在所有使用框架的开发中需要使用的。

Zend_Loader::loadClass() vs FXXX::loadClass()

我首先在Doc Root  目录中创建了 Zend 和 FXXX 目录,用于存放两个框架必要的文件。既然是测试 Loader 那么只要存放必要的 Loader 文件就可以了。顺便可以测试一下两个框架的耦合度。

第一回合,耦合度:

Zend Framework 的耦合度低得超出了我的想象,完成这个测试只需要两个文件:Zend/Loader.php 和 Zend/Exception.php。也就是说完全可以在其他项目中按照 Zend Framework 的类命名方式来使用 Zend_Loader。比如 FXXX 的类命名规则跟 Zend Framework 也是一样的。

FXXX 的表现让我有些遗憾,并没有像口碑传颂的那样有非常低的耦合度。实际上,我在删减的过程中发现,FXXX.php 这个主文件除了同 Exception 目录中的几乎所有的异常类相关外。还同 Config 目录下的配置类相关。同时还有一个为了保正持兼容产生的 Compatibility.php 文件。也就是说如果我在一个 Zend Framework 的项目中认为 FXXX 的 loadClass 非常好,希望使用的话,除非对 FXXX.php 进行比较大的改造否则是无法很干净的使用的。

第二回合,加载的性能:

为了测试加载的性能,肯定要有许多的类来加载。这两个loadClass 本身都有是否已经加载的判断。所以无法用相同的类来在同一脚本中测试。于是我编写了如下脚本生成了 2000 个类。

<?php
$c 
= <<<EOT
<?php
class %s_Foo_Bar_C%d
{
    function %s_Foo_Bar_C%d()
    {
        echo 'Hello, I`m ' . __CLASS__;
    }
}
EOT;
for(
$i 0$i < 1000$i ++)
{
    
file_put_contents("Zend/Foo/Bar/C$i.php"sprintf($c'Zend'$i'Zend'$i));
}

for($i 0$i < 1000$i ++)
{
    
file_put_contents("FXXX/Foo/Bar/C$i.php"sprintf($c'FXXX'$i'FXXX'$i));
}
?>

执行后,会分别在 Zend/Foo/Bar 和 FXXX/Foo/Bar 目录下生成 1000 个类。

然后执行如下代码:

<?php
$t1 
microtime(true);
include(
"FXXX/FXXX.php");
for(
$i 0$i 500$i ++)
{
    
FLEA::loadClass("FXXX_Foo_Bar_C$i");
}
$t2 microtime(true);
$F $t2 $t1;
$t1 microtime(true);
include(
"Zend/Loader.php");
for(
$i 0$i 500$i ++)
{
    
Zend_Loader::loadClass("Zend_Foo_Bar_C$i");
}
$t2 microtime(true);
$Z $t2 $t1;

$colorF $F $Z 'GREEN' 'RED';
$colorZ $F $Z 'RED' 'GREEN';
echo 
"<div style='color:$colorF'>FXXX: $F</div>";
echo 
"<div style='color:$colorZ'>Zend: $Z</div>";
$l fopen('performance.htm''a');
fwrite($l"<div style='color:$colorF'>FXXX: $F</div>");
fwrite($l"<div style='color:$colorZ'>Zend: $Z</div>");
fclose($l);
?>

 执行结果如下:

FXXX: 0.88142681121826
Zend: 0.71647882461548
FXXX: 0.90142107009888
Zend: 0.80371809005737
FXXX: 0.89877319335938
Zend: 0.78475499153137
FXXX: 0.90315580368042
Zend: 0.74558305740356
FXXX: 0.90490698814392
Zend: 0.74327898025513
FXXX: 0.90539908409119
Zend: 0.75572395324707
FXXX: 0.89044094085693
Zend: 0.92172718048096
FXXX: 0.90000414848328
Zend: 0.70924401283264
FXXX: 0.933345079422
Zend: 0.75454902648926
FXXX: 0.89444017410278
Zend: 0.71896600723267
FXXX: 0.91656303405762
Zend: 0.74967002868652
FXXX: 0.89662003517151
Zend: 0.71387505531311
FXXX: 0.88803505897522
Zend: 0.70629405975342
FXXX: 0.90400505065918
Zend: 0.76834392547607
FXXX: 1.0645110607147
Zend: 0.76415610313416
FXXX: 0.92071008682251
Zend: 0.75756502151489
FXXX: 0.90521693229675
Zend: 0.70937299728394
FXXX: 0.93211507797241
Zend: 0.77255201339722
FXXX: 0.88652992248535
Zend: 0.72526407241821
FXXX: 0.8886878490448
Zend: 0.73331189155579

 当然,如果对 FXXX.php 文件进行删减应该可以获得不少性能的提升。不过这违背了这个测试的初衷,不是么?

需要补充的是,Zend Framework 自己曾经有过一个 Zend.php。出于某种原因,这个文件被拆分到了若干个文件中去。详细的内容,请大家看 Zend Framework SVN中 2007-3-9 的 3834 版本的注释。

这次测试,我对 Zend Framework 的 Loader 部分相当满意,它提供了相当好的使用效率和执行效率的平衡点,关于这部分的一些纤细分析,请看

Zend Framework 代码分析——Zend_Loader

对于 FXXX 来说,这个测试所表现出来的内容,虽然并没有我所预期的那样好。但是它依然不失为一个非常优秀的框架。如果能够进一步降低 FXXX.php 文件耦合度,真正实现 L 兄所描述的“在灵活性方面,FxxxPHP 和 ZF 根本就是一个层次的”以及“都是极小的核心 + 可选的扩展功能”,那应该会有更大的飞跃。呵呵~~呵呵呵呵~~希望我说这样的话不会再次让 L 兄觉得恼火又给我扣上一顶"侮辱了所有为解决企业应用面对的困难做出努力的人们"的高帽子。

谢谢大家,谢谢CCTV,谢谢MTC,谢谢所有看过本文,并且谴责本人的所有同僚,谢谢大家。

 

6 thoughts on “关于 Zend Framework 和国产 FXXX 在类加载性能上的测试”

  1. 老子做JAVA所用的JSF框架无论从哪个角度来说,都占有无可比拟的优势,但是我从来不会说JSF比XXX牛B…关键是分析问题要本着实际使用的情况来客观分析,如果FXXX这个所谓的框架在实际生产环节中有不可解决的硬性缺陷,那我宁愿选择过时但稳定的框架,这是熊和鱼掌的道理,哈哈…顺便说上一句,牛B不是吹的,火车不是推的

  2. 针对 loadClass 进行测试没有多少意义
    并不能反映一个框架的好坏
    你打开 loadClass 这段代码看看。
    才几行代码。这代表不了框架。

  3. 关于 Zend_Loader 的代码量问题,请看我之前的随笔。至于这个测试,也并不是决定某个框架的好坏、生死。这仅仅是在一个方面进行一些检验而已。请不要上纲上线。

    至于反映一个框架好坏的测试,由于水平有限,我没有能力做。我看到 phpe 上的一些帖子,牛人 ggg 似乎对 Zend Framework 的缺陷也颇有心得。所以还是请 ggg 来提供一些参考数据吧。^_^

Leave a Reply

Your email address will not be published. Required fields are marked *