Also your methodology for benchmarking looks wrong - I'd like to see two different php files executed through the web server with ab.exe or equivalent
I did experiment with ab.exe, the apache benchmark tool, but it did not seem to work well. I then realized that it might be more appropriate to evaluate the time within the file to execute the page generation. So, using microtime set at the beginning and end, and within the include files, I was able to sum up the time involved to generate the pages. The results also had much lower variability. "Run Time" is the time to include the file, and "Page Time" is the time to generate the page, each 10,000 times.
Speed Test
Total Count = 10,000
-------PHP Version = 5.2.0-------
Run Time Embed = 6.68748784065
Page Time Embed = 0.223108291626
Run Time Replace = 7.04441785812
Page Time Replace = 0.443378686905
Ratio (Replace/Embed) = 1.98728018432
-------PHP Version = 4.3.9-------
Run Time Embed = 1.4540040493011
Page Time Embed = 0.16743636131287
Run Time Replace = 1.8359100818634
Page Time Replace = 0.39892172813416
Ratio (Replace/Embed) = 2.3825274570363
-------PHP Version = 4.4.8-------
Run Time Embed = 1.8318321704865
Page Time Embed = 0.20241498947144
Run Time Replace = 2.1751329898834
Page Time Replace = 0.48875904083252
Ratio (Replace/Embed) = 2.4146385705368
-------PHP Version = 5.2.5-------
Run Time Embed = 1.5818297863
Page Time Embed = 0.145533084869
Run Time Replace = 2.01282501221
Page Time Replace = 0.418002843857
Ratio (Replace/Embed) = 2.8722186727
So, in general, as far as execution is concerned, Replacing is twice as slow as embedding, if these are valid simulations. You do need to keep in mind that we are talking about pretty small differences. One note about str_replace(), is there is not on option to "replace once" and that does hurt the speed, because in these cases, most of the time you only want to replace once. You can do that with preg_replace(), but it runs slower. And creating a "replace_once" function is not as fast as a native function.
I have really enjoyed the comments. What I am talking about is the approach to design, which is why this is posted in this category, and some of this may be just preference and style. Everyone has definitely made me think.
I need to emphasize that I do not, nor have I ever used Smarty-style or pseudo-language templates. My discussion here was mainly about "static" templates, with dynamic content inserted, and how to best manage that.
We have talked about site templates, but we can also include other things as well. For example, I have developed e-mail newsletter systems, where templates were stored in a database. In those cases, embedding PHP is not an option. I did find that it worked better to store a complete template and insert into the template, than to create multiple fields with the header and footer, etc. So, if you ever develop such a system, you might try that and see what you think. If you want to store templates in a database, you will need a mark-up of some kind.
In regards to site templates, over the past 2-/2 years, I have developed about 2 dozen websites. I always generate a standard template and a print template. In only 3 sites, did I need to develop more, and the most I created was 5. So, I have used this technique, and actually have liked it. It is easy to create templates and review them. As I said, they are simply complete HTML documents.
The one thing I have found quite useful, is generating the page last, and I would consider that, no matter what your approach. So, I have all of the content and miscellaneous variables generated and then output the template. I have found that quite useful because you can set session variables or cookies, do header redirects, or create custom error messages from your content. In my case, content is PHP, read using ob_get_contents().
I think if you wish to embed PHP into your template, consider only using echo statements of variables. Do all the conditional stuff elsewhere, if possible. It does make it easier to manage the templates.
(OT, in regards to upgrading to PHP 5, of 24 sites, I only have had 3 where PHP 5 was available. It is still pretty sad out there. I am hoping this changes this year!)