One large include or multiple small includes?

As it stands now, I put all the logic code for specific website functions in a separate include file and include it only if needed. This helps keep the memory footprint of the site small as each logic include is only 5kb - 30kb in size, I think.

However, managing 20 some odd includes (and growing) is becoming a bit of a hassle. Sometimes there are a few (5 - 10) lines of code duplicated in a few includes. When I want to change a few things, I have to open and close several includes. Sometimes I forget what is where even with descriptive file names. :lol: Backing up changed files is a bit of a hassle, too

So, I was wondering what experienced PHP coders think about sticking all of my included logic into a class in one big include file and calling logic functions from my controller as needed. The large include would be loaded with every page view even though 90% or more of the code in it would not be needed. One large include file could hit 500kb or more. I don’t know how inefficient this is going to be with the PHP interpreter having to compile a bunch of unneeded code. But, I keep reading how fast the PHP interpreter is, so maybe this will not be much of a performance issue.

Any thoughts?

Neither. Register an autoload function, and use that. Assuming your names are descriptive of what you’re looking for (i.e., class names are the same as file names), then you’ll have no problems, and never have to think about including classes again.

I like multiple smaller includes. From a server performance point of view the web server doesn’t have to cache a huge include, and if php/apache caching works similar to the way asp caching used to work you’d end up with each web thread re-caching the file. Caching is probably smarter these days though.

Just an opinion, I don’t have any hard data that directs me to use one method or the other.

I think what you are talking about is identifying dependencies.

The dependencies for each script will differ from case to case, I imagine.

For example you may need to connect to your database.

You may need to occasionally format some money, or a date too, lets say.

You may figure that just about every page needs to connect to your database, but the others will depend upon the needs of the calling script.

As such it will surely help to identify families of functions, if you start lumping those families together and removing common code you will no doubt start to identify and evolve “classes” of code all kept in separate files.

One option is to autoload these classes, using the autoload function - but it requires quite a bit of discipline in naming and storing them.

I realise I am trivialising the solution, but in effect you are likely a good candidate for teaching yourself OOP, because a question such as yours becomes moot once you start to master even simple OOP techniques.

Trivial example:


include 'dbconn.class.php';
include 'formatMoney' . $country .'.class.php' ;
include 'formatDate' . $country .'class.php' ;

Yes it’s ok to put commonly used includes in one include or you can group them.

If you are using a opcache, which you should be, it really won’t matter. Even without, it won’t matter. When the size of the file becomes too much you would have gone way beyond measuring the file in Kilobytes (or a few 100 Megabytes).

php 5.+ doesn’t have critical memory leaks, and I think that you need to upgrade your OOP and architectural design using design patterns, and then you won’t experience those problems.