well. additionally the code from the templates might even be cached to the db (we actually had this implemented already)<br><br>an opcode cache would make this unneeded though.<br><br><div><span class="gmail_quote">On 8/4/06,
<b class="gmail_sendername">Bčr Kessels</b> <<a href="mailto:ber@webschuur.com">ber@webschuur.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Op vrijdag 4 augustus 2006 12:23, schreef Dries Buytaert:<br>> We did some preliminary benchmarks and noticed a 10% performance <br>> cost. This cost was not caused by fopen() but by the way variables <br>> were handled. This might be less of an issue with this patch.
<br>><br>> It's well worth exploring this further, IMO, but rather than guessing <br>> we should collect factual data.<br><br><br>Something that is *very* important when benching fopens-freads is the<br>underlying file system and the activity of the HD.
<br><br>I was told that a fopen - fread (php include() ) often does a file lock too.<br>On a server where there is a lot of disc activity this may idle your app for<br>seconds or even longer, since PHP will idle/wait untill it may actually open
<br>the file.<br><br>So in short: make sure you benchmark this on a system that is apropriate.<br>simply benchmarking it on a single site on your localhost will not suffice!<br><br>--<br>| Bčr Kessels | <a href="http://webschuur.com">
webschuur.com</a> | Drupal, Joomla and Ruby on Rails web<br>development |<br>| Jabber & Google Talk: <a href="mailto:ber@jabber.webschuur.com">ber@jabber.webschuur.com</a> |<br>| <a href="http://bler.webschuur.com">http://bler.webschuur.com
</a> | <a href="http://www.webschuur.com">http://www.webschuur.com</a> |<br><br><br></blockquote></div><br>