views:

150

answers:

5

If I had a large number of functions would it be better to keep them all in one large file or would it be better to separate them into several files of related functions. By better I mean more efficient for both maintainability and for the server processing the request.

For example right now I have all my files in a file named include.php. But would it be wiser to have an include file of includes like:

<?php
 include('/functions/user.php');
 include('/functions/admin.php');
 include('/functions/content.php');
 include('/functions/nav.php');
 include('/functions/database.php');
 include('/functions/other_junk.php');
?>
+4  A: 

Definitely separate them, for maintainability sake. I doubt performance will suffer at all, but even if it does (just a teensy bit) you're better off writing maintainable, readable code.

echo
+1 for propagating maintainability and readability in php.
Willi
+2  A: 

In terms of maintainability, it's usually better to separate your functions into related groups. ( like you showed above, user.php would be only the user-related functions ).

You should only have a file that has all of those includes if you know that you'll need all of the included files every time you need to include any file. Otherwise, it defeats the purpose of having that 'catch-all' file.

Jacob Relkin
+2  A: 

In my experience multiple includes and/or requires generally arent goping to set you too much back if youre talking a couple dozen or so files for function libraries. Especially if you can manage to only call the statement for a particular file once during a request lifecycle.

Where it starts to show performance hits is if you get into OOP or a highly complex functional/procedural type architecture where there may be hundreds of different classes/files. But generally at that point youll have hopefully done some kind of mitigation via caching/compiling.

prodigitalson
+2  A: 

You want to be sure you're using a PHP cache like XCache or APC. Your PHP files should then all be in memory and you shouldn't be worried about your includes hitting the disk at all.

I would definitely find it easier if you broke up like minded functions/classes into their own files.

Klinky
XCache and APC, unless specifically configured otherwise, will check for the file modification time to determine if they should process a new version of the file. This affects performance quite a bit if there are a large number of includes. On a production server where the code is fixed you should really turn this off. You'll get a nice little performance boost at the cost of having to manually flush the cache when you upload a new version of the code.
Mike
A: 

I have a list of includes in a central .config file.

For all OOP classes though I use autoload -> I know it's slightly slower, but it saves having to including them as I make a new class. And they're only loaded as required.

As an aside, include is quicker than include_once as it doesn't have to check if the file has been included already.

niggles