Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /share/CACHEDEV1_DATA/Web/www/libraries/UBBcode/text_parser.class.php on line 228
Evil Eval

Comments Blog About Development Research Sites

Evil Eval

Feb 2, 2008
About a year ago I played with the idea to store PHP code in a database. This would greatly simplify the whole backupprocess, allow for some simpel version control system and would even mean that by just putting a loader on a server I could run my entire site from anywhere I wanted.

Moreso, if I was away and found a bug in the code, I could just go to an edit page and modify the code, without having to install FTP clients, editors, etc.

In the end I decided it would be too much of a hassle, especially since by then I discovered SVN which is the way to do version control, and because of the risk of writing some bad code in the database, saving it and then discovering that the editor was bugged. Not to mention all the trouble with syntax highlighting, lineendings, etcetera.

Reason I'm bringing this up is that on GoT the discussion about this has flamed up, with definately some good points on both sides. What really turns the table for me though is this little test script:

Code (php) (nieuw venster):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function calculate($x, $y) {
  return
$x * $y;
}

$start = microtime();
  
for(
$i = 0; $i < 1000; $i++) {
  eval("calculate($i, $i);");
}
echo
microtime() - $start . '
'
;
  
$start = microtime();
  
for(
$i = 0; $i < 1000; $i++) {
  calculate($i, $i);
}
echo
microtime() - $start;


Basicly this just squares the iterator a thousend times - which becomes an increasingly large number as the iterator grows, enough to give a good estimate of performance differences.

They where shocking.

For the normal calculate call, processing time was 0.001803. Quite nice for an old webserver. The eval'd one however ranks in a grand total of 0.016866! That is almost 10 times as slow as doing it the normal way!

One could argue that, if I had put the entire for loop inside an eval loop, the difference would be less severe - and they would be right. In that scenario the eval'd code runs in 0.001961s, which is still about 9% slower. The alternative - writing stored code to file and include the file - is probably not much better either.

So there you go - almost a tenth performance drained away for almost no reason, not to mention the horrid maintainance you'd get. I think I'll stick to files for now ;)

Or, to put it in the words of PHP's creator Rasmus Lerdorf: "If eval() is the answer, you're almost certainly asking the wrong question."

FragFrog out!

New comment

Your name:
Comment: