📜 ⬆️ ⬇️

Eval or include?

I am developing one of the current projects on my own framework, running it in parallel and finishing it. Why did I need to reinvent the wheel, and how it differs from the existing ones, I will write when I present it to the public. Now I want to share some thoughts about performance and at the same time listen to the opinions of colleagues. Perhaps my observations will be useful to those who do not use frameworks.

When I had to implement a comment tree, I encountered the need to recursively call a view (view in MVC). Since I, and practically everywhere, have views, these are regular files with chunks of HTML code and the ability to insert PHP, they are connected using include. I felt uneasy when I introduced how this include is called recursively hundreds of times. The first thought is to thrust the presentation file at the first request into memory and then execute it via eval. This approach will allow caching the code of views, and even store it in a database. Since eval eats only PHP, and our views are not pure PHP code, we frame the contents in '?>' And '<? Php'.

So, for the cause.
')

Tests

To begin with, in various ways in a loop, we will derive a simple view 'view.php' containing, for example: i=<?=$i?>

CodeTime with
(in brackets - with eAccelerator)
  for ($ i = 0; $ i <100; $ i ++) include ('view.php'); 
0.0058141 (0.002068)
  for ($ i = 0; $ i <100; $ i ++) {$ code = '?>'. file_get_contents ('view.php'). '<? php';  eval ($ code);  } 
0.005527 (0.0056472)
  $ code = '?>'. file_get_contents ('view.php'). '<? php';  for ($ i = 0; $ i <100; $ i ++) {eval ($ code);  } 
0.0015929 (0.0016122)


And recursively

CodeTime with
(in brackets - with eAccelerator)
  $ i = 0;  include ('view.php');  ---------- view.php ---------- html <? php if (++ $ i <100) {include ('view.php');  }?> 
0,006865 (0,0019491)
  $ i = 0;  $ code = '?>'. file_get_contents ('view.php'). '<? php';  eval ($ code);  ---------- view.php ---------- html <? php if (++ $ i <100) {$ code = '?>'. file_get_contents ('view. php ').' <? php ';  eval ($ code);  }?> 
0.008599 (0.0087898)
  $ i = 0;  $ code = '?>'. file_get_contents ('view.php'). '<? php';  eval ($ code);  ---------- view.php ---------- html <? php if (++ $ i <100) {eval ($ code);  }?> 
0.0034332 (0.0032461)


findings

The first thing that catches your eye is that options with eval cannot be optimized and cached with eAccelerator. Therefore, if you use it and you do not need other advantages of eval, it is better to stop at include.

Using eval makes sense where views are called multiple times, but it is not possible to use accelerators. Or if views are stored in the database.

The error handling in eval is a bit different. If an error of code parsing occurs, for example, the script execution is not interrupted. This can be useful in some cases. But at the same time, the error message looks different, which can be a bit confusing:

Parse error: syntax error, unexpected T_ECHO, expecting ')' in /www/test/eval_vs_include/test.php(39) : eval()'d code on line 4

Here the indicated error occurred in the 4th line of the view.php file, which was fed into eval, located in the 39th line of the test.php file. Of course, nothing prevents us from displaying the name of the included file, if eval returned false. Considering that the work on errors is not a regular mode, and errors are not displayed on the working draft, I consider this drawback to be not significant.

Eval

+ Faster than include if accelerators are not used
+ Possibility of caching the code of views in the framework or template engine
+ Ability to store views in the database
+ Script execution is not interrupted when errors occur.
- Not optimized and not cached by external accelerators
- The output of errors differ from the usual
- On some hosting eval may be prohibited

Include

+ Works everywhere
+ External accelerators greatly increase productivity
- Low speed without accelerators
- There is no possibility to cache the code connected from the file in your engine
- Link code can only be in the file

It should be noted that the CodeIgniter eval framework is also used to display views, but only if the settings indicate the need to replace short '<? =' With '<? Php esho' and the short tags in PHP settings will be disabled. In all other cases, include is used. CakePHP always uses include.

Source: https://habr.com/ru/post/24038/


All Articles