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

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

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

如何兼顧代碼結構容易理解和性能是個挑戰

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

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

那么實現的挑戰有兩個：

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

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

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

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

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

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

no

這個設計大約減少了一倍多的編譯結果。性能提升了大約20%，極大的優化了PHP代碼解析損耗。