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