Best Organization of PHP Include Files?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

In my PHP code, I typically break my functions into groups (usually based on  
the data type they operate on), and then include the files, i.e.:


The included files never contain any code that gets executed directly (it is  
all in functions, which are then called from the code in the page that is  
doing the including).

I've always found PHP to be very fast, but in large projects a large number  
of files with a lot of functions could be included.  I have to assume that  
the PHP interpreter requires some time to parse each include file.


a)How inefficient is this?  (I.e. how much parsing does the interpeter do of  
functions that are included but not yet called?).

b)What is the best paradigm for managing include files?

Thanks, Dave.
David T. Ashley              ( (Consulting Home Page) (Personal Home Page) (GPL Publications and Projects)  

Re: Best Organization of PHP Include Files?

David T. Ashley schrieb:

Quoted text here. Click to load it

Yes, it does. But this should not be your intention for reorganizing the
file structure. Only ease of management and increased maintainability
should be of any concern here.

Quoted text here. Click to load it

First of all, the slowest part of the including is actually looking up
the file (include_path) and opening it. The parsing is very quick
compared to that. The filesystem part inproves over time because modern
filesystem do a good job of caching the accesses. Only the first lookup
is slow.

If you run into any performance issues then the first thing to do is
install an opcode cache like APC or eAccelerator because this gives
performance at almost no cost beside some RAM. These tools make it
possible to completely skip the lookup phase AND the parsing because the
most used code is kept in RAM in compiled form. A tip: Minimize your use
of the _once variants of include and require if you plan on using APC
because this MAY cause degraded performance of the cache.

This about a quick performance boost. Now to structural topics...

Quoted text here. Click to load it

Some considerations: First of all, you have to clearly seperate file
that are only included once per request from those you might be
including multiple times. All files declaring functions and classes may
only be included once because subsequent includes would result in an
error. These are "library files" Files containg just some HTML snippets
or simple linear PHP code may be included multiple times, so they
somehow all belong to some type of "template file". For these two types
of files the usual managing concepts only apply to library files. And
here are some of those concepts:

- Only include what you use. This is a goal not easily achieved as you
already said so you always have to find a compromise. But this rule
makes it clear that it is a bad idead to include all of your libraries
at the beginning of each PHP script.

- Use a clear scheme for filenames. Structure is key when it comes to
building up a code library. Only if you easily know where each function
is then you can avoid blindly including too many files.

- For larger applications (more than 30 files or so): Follow the front
controller paradigma. Always call index.php for your application and
handle the navigation with other parameters. Different PHP entry points
are fine for small projects because you can easily define which files
every entry point needs but you lose control when the project becomes

- Tip: Use static class functions instead of plain functions. Why? First
of all, it reduces the "pollution" of the global namespace. If you
decide to use third party libraries at a later date then the risk of a
name collision is bigger with ordinary functions. Use classes and prefix
 the class names with a unique prefix for all your classes. You could
for example use "DTA" as a prefix. And classes allow for the next tip ;-)

- Use __autoload(). A strict directory structure and the "one class per
file" concept help to automatically include only used code. For example,
if you put the class DTA_Beer_Brewery in the directory
DTA/Beer/Brewery.php somewhere in your include_path and you create a
matching __autoload function, the you can just forget about including it
manually. You just call DTA_Beer_Brewery::getGuinness() somewhere in
your code and the autoloading manages the inclusion of the file.

Hope that helps.


Just to be absolutely certain: you are the female of your species?
[John Crichton, FarScape 113]

Re: Best Organization of PHP Include Files?

David T. Ashley wrote:

Quoted text here. Click to load it

V. Sensible.
Quoted text here. Click to load it

Sort of. It's got to parse the code whether its in one big file or fifty
small ones. Actually, that's not true all the time either - if you use a
code cache it doesnt't have to parse each file every time - and greater
granularity improves caching effectiveness.

There is a small overhead from loading additional files but I think its
usually worth spending on hardware what you're saving on programmer time.
Quoted text here. Click to load it

It depends. If you're using php5 an OO programming then fitting your include
files around the autoloader is a very good idea. If you run mutliple
different environments for development, testing, staging and publishing
then a hierarchy of include directories in your include_path allows you to
override different files at different stages of the deployment.

You might as well ask what's the best of car to buy - its the same answer,
the one that's right for you.


Quoted text here. Click to load it

Site Timeline