SMARTY只用了tags和row两个变量，而PHPLIB template则多了模板文件的 handler，还有一个莫名其妙的out。说实在的这个out我当初学的时候就不知道 为什么要存在，现在看起来，还是别扭。为什么SMARTY少那么多处理语句 呢？答案是工作由引擎完成了。如果你喜欢钻研源程序，可以发现在 Smarty_compiler.class.php里有一个名叫_compile_tag()的函数，由它负责把 section这个标签转换成php语句。这不是一个普通的标签，它带有参数和数 据，节省了脚本编程的工作量，而模板标签上的工作量相差又不大，可以判定 在易用性上SMARTY高出一畴。
下面该轮到我们最关注的速度了，毕竟对于一个熟练的web开发者来说，掌握再 困难的工具不过是时间问题，何况模板引擎这种学习曲线平缓的技术。而速度 则是web应用程序的生命，尤其是模板引擎使用在并发访问量很大的站点上，这 点就更重要了。测试开始前，我觉得PHPLIB template会在这一环节上胜出，因 为它经历了很多次升级，已经基本没有什么bug,而且SMARTY的引擎个头太 大，不像它的对手只有两个文件。
果然，测试结果如下图，PHPLIB template有25%的速度优势：
但不会一直这样，我又按了一次刷新，这次得到了不一样的结果：
PHPLIB基本没变化，但是SMARTY提高了25%的速度。继续刷新，得到的都是 类似于第二次的结果：SMARTY比PHPLIB template 快上近10%。我想这就是编 译型比解释型快的原理了。SMARTY引擎本身就很大，加上还要把模板编译成 php文件，速度当然比不上小巧的PHPLIB template。但这只是第一次的情况。 第二次接到请求的时候，SMARTY发现该模板已经被编译过了，于是最耗时的 一步被跳过了，而对手还要按部就班地进行查找和替换工作。这是编译原理里 讲到的很经典的"用空间换时间"例子。
五、结论
结论就是如果你已经爱上SMARTY了，那么还等什么呢？当然并不是说它就全 能，就如同我用MVC模式来写我的个人网站，非但没有减少工作量，反而总是 要为不同层次间的耦合劳神。
SMARTY不适合什么呢？举个手册里的经典例子：天气预报网站。我还想到一 个：股市大盘。在这种网站上用SMARTY会由于经常的重编译而效率偏低，还 是PHPLIB template更为适合。
本文并不是为了对比两种引擎，而是为了说明SMARTY的优势。使用它最有意 义之处在于它是PHP新体系的一部份，作为一支独立的力量，除了.NET和JAVA ONE这两大体系之外，大中型web开发还有别的选择。这对于GNU项目来说， 其意义无异于刘邓大军千里跃进大别山。
参考文献
SMARTY官方站点：smarty.php.net
王晨：《在PHP世界中选择最合适的模板》
本文中测试程序下载：test.tar.bz2
