David T. Ashley schrieb:
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.
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.
Questions:
a)How inefficient is this? (I.e. how much parsing does the interpeter do of
functions that are included but not yet called?).
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...
b)What is the best paradigm for managing include files?
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
bigger.
- 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_Brewer y 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_Brewer y::getGuinness( ) somewhere in
your code and the autoloading manages the inclusion of the file.
Hope that helps.
OLLi
--
Just to be absolutely certain: you are the female of your species?
[John Crichton, FarScape 113]
