程序員們在進行PHP代碼編程中總會希望對自己的代碼程序進行最優(yōu)化的操作，使程序盡量的輕便簡潔。我們在性能分析shopex性能的時候。#t#

發(fā)現(xiàn)用在PHP的語法解析上的損耗占了很大比重，如果用valgrind看他的C調(diào)用的話，就會發(fā)現(xiàn)大約50%的時間被用在lex&yacc上面。也就是由PHP代碼轉(zhuǎn)成opcode的部分。即PHP代碼解析損耗。

這個方面PHP代碼解析損耗的優(yōu)化極限目標是： 一個訪問只運行一個PHP文件，并且這個文件里不包含任何與這個流程無關(guān)的代碼。

如何兼顧代碼結(jié)構(gòu)容易理解和性能是個挑戰(zhàn)

我們的處理思路是，通過類似smarty的編譯系統(tǒng)，將訪問編譯成一個個文件：因為shopex是mvc的結(jié)構(gòu)，那么編譯粒度就每個控制器的方法對應(yīng)一個流程文件。

當控制器第一次調(diào)用時，通過一種方法監(jiān)控流經(jīng)的每個model-method，子過程等等，最后抽取剝離出來，加上公用的數(shù)據(jù)庫連接函數(shù)，配置文件等等一起組合成一個單一的終極PHP文件。
至于緩存的更新基本就是版本的更新，每次升級的時候。touch一個cachestat文件的最后修改時間即可。

那么實現(xiàn)的挑戰(zhàn)有兩個：

* 一個叫model的函數(shù)化 (這樣叫很酷，有點像虛的死神化) 。是弱化model層對象特性，讓類退化為僅是函數(shù)的容器，減少繼承，重載這些應(yīng)用。
* 二是實現(xiàn)一個自己的編譯引擎。

上面兩條最新的shopex485已經(jīng)走了很遠了，商品和訂單的函數(shù)都已經(jīng)拆分了。第二個PHP代碼解析損耗的解決辦法是我們自己實現(xiàn)了一個叫tramsy的解析器( 翻轉(zhuǎn)(smart)+y )，特點是把大量的插件改成了編譯型。強化了編譯插件的特性，增加了一種編譯型modifier的插件類型。并且提出了變量預(yù)綁定的概念：

{if $var=1}  
yes  
{elseif $var=2}  
no  
{else}  
what?  
{/if} 

如果是原生的smarty，生成的代碼是：

vars['var']==1){ ?> 
yes  
vars['var']==2){ ?> 
no  
what? 

如果在tramsy里，程序員預(yù)測var一定是1，并且有把握在其值改變的時候系統(tǒng)自動清除模板緩存，就可以把他設(shè)置為”預(yù)綁定變量”
那么最終生成的代碼就是：

no

這個設(shè)計大約減少了一倍多的編譯結(jié)果。性能提升了大約20%，極大的優(yōu)化了PHP代碼解析損耗。