程序員們在進行
發現用在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代碼解析損耗。
