Include files including includes ;)

I’m just curious how much overhead multi-included requests are on the server. I’ve been programming PHP for a few years now and I’ve written my own CMS and a lot of custom one off functions that do particular tasks that I repeatedly seem to encounter. I’m at the point now where I’m generating code to solve about 75% of the repetitive tasks I am faced with but I’m noticing my include files are getting rather large, ugly and difficult to read through. So I was thinking about storing each function I’ve written in it’s own file, like “function_adjust_item_inventory_count.php” and then including only the necessary functions required into one main include for that specific page request. So for something dealing with the inventory it might have an include file that includes 10 or so functions that relate to the inventory system.

Is this a good idea? or is there a better way around this? My biggest fear is that this might add noticeable delay in the page render times.

I recognise your dilemma from my own past experiences, you are becoming overwhelmed by your own success in identifying and centralizing your own code but lack a prolonged disciplined way of identifying things. As the months/years pass you slowly develop different naming conventions, and start investigating different methods then when you look back you cannot quite remember what does what.

I bet you lose a lot of time trying to find stuff you know you’ve written, but have to look at old code to see what the dependent file is called and its function signature.

Taking some of your points out of order:

So for something dealing with the inventory it might have an include file that includes 10 or so functions that relate to the inventory system.

If they are so related then it might be time to look to using OOP techniques.

So I was thinking about storing each function I’ve written in it’s own file, like “function_adjust_item_inventory_count.php” and then including only the necessary functions required into one main include for that specific page request.

Another reason to use OOP and then PHPs autoload feature.

This is where the naming of things becomes critical, and taking the time to study OOP properly and with it the associated “enterprisey” disciplines will (eventually) make make you a better programmer because it will expose you to predictable guidelines e.g classes are described with nouns, their methods with verbs.

Given your comments here is a trivial example of what I mean let say your inventory is of T shirts, and you operate an online shop.


<?php
// autoload will go and find the file containing this sole class
// if you have set everything up correctly, include directories etc
// this file will be auto discovered var/www/includes/classes/tshirtshop.php

$tees = new TshirtShop;

// TshirtShop is "A tee shirt shop", a noun

$tees->updateInventory(23);

// I am telling you "A tee shirt shop" to go away and "update inventory",
// not update a price, not update a colour ... update, a verb.


Your question seems to me to be more about making yourself more productive and OOP would seem to offer the structure and benefits you are seeking - I have only highlighted a couple of benefits - those which address your specific points.

Have you looked at using OOP previously?

My biggest fear is that this might add noticeable delay in the page render times.

If your app is not slow, I would not worry about it, either prove it or disprove it. Add more RAM or add a memcache like APC first. If you are a metal hugger and really want to peer into the guts of what is going on install XDebug on your dev server and go through your cachegrind files – that’ll tell you what PHP is up to, but its likely to be nothing compared to the amount of time you spend connecting and moving data from your database.

The slow query file on your database will likely throw up the most likely candidates, or maybe you have old nested queries that could benefit from some Joins instead.

Answer: a lot of overhead. The slowest part of executing any PHP code (or doing anything on a modern computer) is hard drive access. A computer can read from RAM hundreds of times faster than it can read from a hard disk.

If you are running on a dedicated server with a PHP accelerator installed, this isn’t going to be much of an issue because the PHP opcode will be cached. However, if you are running on a shared server, this will be a very big deal.

A lot of people have been complaining about slow loading times with Wordpress the past few years. The reason for the slow loading is because the base installation of Wordpress 3.x included 76 or so PHP files for every pageview. Add in some plugins and that grows even higher. Think about it: a shared server has to seek, read, load into memory, and execute 76 PHP files with every pageview. That is going to take a lot of time, relatively speaking. Database access takes even longer than file system access.

That sounds like a horrible idea. Then what happens when you have to find some specific code? Are you going to hunt through dozens of PHP files to find what you are looking for?

Most modern PHP IDEs have code folding so you only see the function definition. Even a PHP file with hundreds of functions is easy to manage with code folding. And you can hit control + F to find what you are looking for inside the file instead of hunting through many files.

On a dedicated server with a PHP accelerator, this would work OK. On a shared server, the less included files the better.