How to efficiently optimize PHP code parsing loss_PHP tutorial

Programmers working on

found that the loss in PHP syntax parsing accounts for a large proportion. If you use valgrind to look at its C calls, You will find that about 50% of the time is spent on lex&yacc. That is the part that converts PHP code into opcode. That is, PHP code parsing loss.

The optimization limit goal of PHP code parsing loss in this aspect is: Only one PHP file is run per access, and this file does not contain any code unrelated to this process.

How to balance the easy-to-understand code structure and performance is a challenge

Our processing idea is to compile the access into files through a smarty-like compilation system: because shopex is an mvc structure, Then the compilation granularity is that each controller method corresponds to a process file.

When the controller is called for the first time, each model-method, sub-process, etc. flowing through it is monitored through a method, and finally extracted and stripped out, and the public database connection function, configuration file, etc. are added. etc. combined into a single final PHP file.
As for the cache update, it is basically a version update, every time it is upgraded. Just touch the last modification time of a cachestat file.

Then there are two implementation challenges:

* One is called functionalization of the model (it’s cool to call it this way, a bit like a virtual death). It is to weaken the object characteristics of the model layer, let the class degenerate into a container of functions, reduce inheritance, and overload these applications.
* The second is to implement an own compilation engine.

The two latest shopex485 above have gone a long way, and the functions of products and orders have been split. The second solution to the loss of PHP code parsing is that we implemented a parser called tramsy (flip (smart) + y), which is characterized by changing a large number of plug-ins into compiled types. The features of compiled plug-ins have been strengthened and a compiled modifier plug-in type has been added. And the concept of variable pre-binding is proposed:

<ol class="dp-xml">
<li class="alt"><span><span>{if $</span><span class="attribute">var</span><span>=</span><span class="attribute-value">1</span><span>}  </span></span></li>
<li><span>yes  </span></li>
<li class="alt">
<span>{elseif $</span><span class="attribute">var</span><span>=</span><span class="attribute-value">2</span><span>}  </span>
</li>
<li><span>no  </span></li>
<li class="alt"><span>{else}  </span></li>
<li><span>what?  </span></li>
<li class="alt"><span>{/if} </span></li>
</ol>

If it is native smarty, the generated code is:

<ol class="dp-xml">
<li class="alt"><span><span>vars['var']==1){ </span><span class="tag">?></span><span> </span></span></li>
<li><span>yes  </span></li>
<li class="alt">
<span>vars['var']==2){ </span><span class="tag">?></span><span> </span>
</li>
<li><span>no  </span></li>
<li class="alt"><span>what? </span></li>
</ol>

If in tramsy, the programmer predicts that var must be 1, and is sure that the system will automatically clear the template cache when its value changes, he can set it to "pre-binding" "Defined variable"
Then the final generated code is:

no

This design roughly reduces the compilation results by more than double. The performance has been improved by about 20%, and the PHP code parsing loss has been greatly optimized.

http://www.bkjia.com/PHPjc/446133.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/446133.htmlTechArticleProgrammers are discovering that the loss in PHP syntax parsing accounts for a large proportion. If you use valgrind If you look at his C calls, you will find that about 50% of the time is spent on lexyacc. ...