Calling the same template files 20 times - Optimization advice

[andROO]

Hi there,

I've developed a simple templating engine for personal use. Now I have a dillema. Here's the situation:

A database query generate a list of results. Now, a row.php template file is called multiple times (20 times for instance, if 20 results are displayed) to render the data display. Is that a bad I dea? Should I instead have a single rows.php template file and use a "foreach" loop to render each row or would that make no difference in terms of code optimization?

The reason why I need a row.php file is to keep the html code as clean as possible from php code, thus keeping the "foreach" away.

Hope this makes sense, and thanks for your advice.

[Dan Grossman]

It doesn't really matter either way, the overhead in doing an include() is miniscule. Especially if there's an opcode cache on the server (APC, eAccelerator, etc) caching the compiled code already. If you prefer the separate file for individual rows, then use that.

[andROO]

Great, thanks Dan!

[elias]

The reason why I need a row.php file is to keep the html code as clean as possible from php code, thus keeping the "foreach" away.

i did similar in an old project and never again. the problem
is that it is likely that your foreach (or for etc) statement
and the include needs to be changed at once.
you'll end up looking and switching files much more and that
alone isn't worth it. (at last to to this for any loop)

[andROO]

the problem is that it is likely that your foreach (or for etc) statement and the include needs to be changed at once.
you'll end up looking and switching files much more and that
alone isn't worth it. (at last to to this for any loop)

Thanks for stopping by, elias. I'm not sure I am getting you though. I don't think there's a "switching files" problem here at all, at least in my situation. We're speaking about a single file, and two ways of dealing with it. Well, I'm using a debug function to monitor the memory load and can't see a significant difference when testing both cases so I guess Dan has a valid point afterall.

If anyone has a different point, please let me know, I appreciate it.

[allspiritseve]

The reason why I need a row.php file is to keep the html code as clean as possible from php code, thus keeping the "foreach" away.

A more worthy goal would be to keep your business logic separate from your presentation logic. In this case, the foreach loop is presentation logic and it should be in the template.

[andROO]

A more worthy goal would be to keep your business logic separate from your presentation logic. In this case, the foreach loop is presentation logic and it should be in the template.

I understand that statement perfectly, thanks. I've done some reading and I do keep in mind the principle of separation when it comes to business logic and presentation logic of an application. In this case though, I'd prefer to make an exception and take all the scary code away from the user who doesn't know much about it and would rather break it than adjust it. Besides, I don't see any strong reasons to keep the foreach loop in the template if I can easily take it away as it doesn't need to be at hand, I think. It's part of the engine so it must be given to the business logic, not the presentation...

[allspiritseve]

In this case though, I'd prefer to make an exception and take all the scary code away from the user who doesn't know much about it and would rather break it than adjust it.

If your user is ok with html, a little php won't kill them. If you name your variables clearly, it reads like english anyways:

<?php foreach ($articles as $article): ?>

Besides, I don't see any strong reasons to keep the foreach loop in the template if I can easily take it away as it doesn't need to be at hand, I think. It's part of the engine so it must be given to the business logic, not the presentation...

PHP was meant from the start to have the capability to be embedded into HTML, hence always encasing PHP code in brackets: <?php ?>. (Not all PHP... just presentation logic as I said before). In general, you want to keep together things that are commonly changed together. A foreach loop and the code it encases have a contract between them, and the encased code is expecting what the foreach loop passes to it. If you change one, you're probably going to have to change the other. That's why I think they belong together. It may not save any code execution time, but it will save you a lot of modification time down the road.

[andROO]

Thanks for sharing your ideas, allspiritseve!

[Mastodont]

take all the scary code away from the user who doesn't know much about it and would rather break it than adjust it
You can also preprocess templates in order to use "placeholders" for common PHP code. I assume that Smarty's caching is the same principle - user prepares template without PHP code and Smarty transforms it into second "hidden" file.

[Vali]

btw, includes are linear in php, so if one include takes 10 milliseconds (random number there), then 2 will take 20 milliseconds, 10 will take 100 milliseconds and 1000 will take 10000 milliseconds.

Usually, what you "should" do is make your includes the way your doing them, and then cache the page / block of the page that doesn't change.

Example for some page:

> Header*
>> Common header html includes
> Left Menu Bar*
>> User Info+
>> Menu Items
>> Quick Search
> Right Content (search results)**
>> pagination
>> mini profile view+ (in a loop 20 times)
>> pagination
> Footer*
>> Common footer links

> Means include
>> means include in my include
* means you cache the HTML after the includes in that block
+ means you cache the HTML for that block (can be used my multiple users)
** means you need some special cache - you cache the page and pagination, and insert the search results in it, then cache everything again.

The idea is this:
- The first time a page gets loaded, all includes happen (31 includes in that example, + lib includes)
- The second time a page gets loaded, you won't have to use all the includes you included the first time, since they didn't changed. So you just serve a cached version of the page (no html include, no db queries no nothing, just your main lib include) So this time you have just the lib includes.
- If you see the search results page again, but with different results, you have most the page cached, so all you need to include are the results, so you end up with 20 includes + lib includes.

Thing is, this will speed up your stuff, but chances are there 1 million other things you can do to speed it up with allot less work / minor logic change.