My current workflow I include function and class files as and when I need to. However, this can get quite messy with you have quite a lot of them in which some depend on others.
So I'm considering using a head file which includes on the files in the includes directory. But my question is, are there any PHP performance issues for doing this over including as an when i need. Often times I have to use include_once, so doing 1 big include would get rid of the need for this.
The best approach would probably be autoloading. You do not need to (manually) include any class at all, then. Take a look at this. I recommend using the spl_autoload_register()-function. That would resolve dependencies on the fly. The performance of includes is really irrelevant in most cases. The slow things usually happen in other places. Using autoloading has the added benefit of lazy loading. You do not load source files that are not in use. This might even speed up your application.
Normally performance (speed) in PHP is not affected by the amount of codelines or files but of:
Access to db
Access to file system!!!
Access to third party APIs (SOAP...)
Coding style
PHP code is interpreted on the fly. If a given piece of code is not used, it will not be 'compiled' and so will not incur a performance hit.
However, all code on a given page (and its includes) goes through a syntax check so that may slow things down a little.
Certainly I would consider the includes that you have and whether or not you really need them.
There is a performance effect but it is not a very significant one. Do whatever makes it quicker and easier for you to write the code. If down the line you find that you really need that 1ms back, and you have already trimmed all of the other fat elsewhere, then go for it. Otherwise you are throwing away development time on trying to be "perfect" when it never actually makes a practical difference.
I would recommend you look at autoloading: manual. I would also recommend using spl_autoload_register over one __autoload() function as it allows for greater control with separating out modules or namespaces.
Well including files does have a hit on the performance of your app because it needs to read your app from the disk but if you stay below about 100 files this is trivial.
Btw if you don't like having to include your class files every time check out the magic method autoload:
function __autoload($class_name) {
include $class_name . '.php';
}
http://php.net/manual/en/language.oop5.autoload.php
Related
So far I have about 3 PHP includes on my site.
<?php include("includes/header.html"); ?>
Is there any reason why I shouldn't add a ton of these?
Not really. They're used quite often and liberally—though more often than not, to include other PHP files. Those PHP files then often include other ones, so there's really no concern.
By the way, if you do use this technique to include other PHP files (e.g. library files with functions you're using), it's a good idea to use require_once (there's also include_once, as well as plain require); require will cause an error if its argument cannot be found, and won't continue trying to render the page. require_once (and include_once) will not include the same file more than once, even if you call require_once (or include_once) from different places.
I suspect that you are doing something like this:
<?php
include("session_and_headers.php");
include("top_nav.html")
include("right_sidebar.html");
?>
... actual content generation code ...
<?php
include("footer.html");
include("js_loader.php");
?>
There is nothing inherently wrong with that for simple static sites, or situations where users will have only several distinct views.
But, what happens if you want to use a slightly different side bar on only certain types of pages? Where do you put the logic to determine that so it is obvious to the next person who inherits your code?
If you get into those kinds of complexities, I recommend going with the MVC approach (even if you mostly use the view/controller aspects of it).
If you're doing a nn page site in PHP that just needs to share common elements, then there is no reason to avoid simply including the files as needed.
Don't look at this so much as is it bad for PHP, look at it more as is it hard to maintain?
There's one advantage to writing object-oriented code and upgrading to PHP 5: you can avoid a "ton of includes" using class autoloading.
Only downside is performance - each include costs you system calls. With 3 or 10 it's all small change unless your traffic is huge, but about 100 may be a problem. The solution is to use a bytecode cache (like apc) and set your realpath_cache_size variable to higher value (default is enough for about 100-200 files, depending on the path lengths).
Other than that - not much of a problem.
I'd like to check if my understanding's correct about require_once(). I have a bunch of functions in file foo.php. Let's say 7/8 out of them are always used, and one of them's rather rare and rather large. I have to keep this function's definition in foo.php. Can you tell me if the following approach achieves anything, and if you think it's worth what it achieves.
Take out the body of the function and put it in an external file.
Redefine the original function to require_once() that particular file and pass execution over to the helper function.
I understand this could save server memory on the requests where that function isn't run. What exactly am I saving though? Just the memory it takes to hold the body of the function? That would mean it would have to be a pretty big function before being worth it I guess. Also, if I'm using something like APC does it become less useful?
Please correct or add to this as appropriate!
Thank you very much.
I highly doubt you will gain anything from refactoring it into a separate file. Also, do you actually have any problems with the code as it is now that makes you consider this? You know premature optimization is the root of all evil. Profile your code to see if and where it has bottlenecks before you waste your time on pointless µoptimizations.
Update: From your comment to Gordon I see you're using Drupal: This method doesn't work there, because Drupal is heavily object-oriented already. What is described here is making use of the Autoloading mechanism for a function-based project using static classes.
As Gordon says, this will save memory only for really incredibly huge functions. In my experience, though, loading includes into memory takes up much more space than the exact number of bytes needed to hold the code. I'm not a PHP internals expert, but I assume the code is parsed or at least preprocessed either way.
Assuming your PHP application is entirely function-based with no OOP, one idea that comes to mind that you could use to split up your includes is putting your functions into classes, and making use of the autoloader mechanism:
class maintenance_functions
{
public static function xyz() { ................ }
and start calling them statically:
maintenance_functions::xyz();
one class would occupy one file.
Group all the rarely used functions into separate files.
Then, you could make use of the Autoloading mechanism. This will load needed classes automatically at the point they are needed. If I for example, call
datamining_functions::xyz();
the autoloader will look for the file containing datamining_functions and include that. This eliminates the complete 'require()' hassle and lets you concentrate on how to group your functions most efficiently.
This is not a real transition to OOP: We just use class constructs to group the functions, in order to be able to use the autoloader. It should be possible to migrate functions into such classes without the need for major rewrites.
You should use Xdebug to find out the answer - worth or not is subjective.
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');
?>
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.
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.
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.
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.
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.
I'm in the process of creating a PHP site. It uses multiple PHP classes, which are currently all in one PHP include.
However, I am using Aptana IDE, and the file is now starting to crash it (it's around 400 lines). So I was wondering whether there would be any negative impact of including all the files seperately.
Current:
main file:
include("includes.php");
includes.php:
contains php classes
Suggested:
mainfile: main file:
include("includes.php");
includes.php:
include("class1.php");
include("class2.php")
Multiple PHP includes are fine, and 400 lines should not be a big deal. My concern would be with the Aptana IDE before I'd even consider my code to be the problem.
Breaking up your code into multiple PHP modules helps you to take a more object-oriented approach and simplifies your code base. I recommend it.
An IDE crashing because of a 400 line file? I'd find a new IDE.
However, it is better to separate classes into separate files. Perhaps not strictly one class per file, but only closely related classes in the same file.
For just two files, the cost won't be too great ; for hundreds of files, it might be a bit more... But, then, another problem to consider is "how do I determine what goes into which file ?"
Nice answer for that is "one class per file" ; and, for those, "one directory per functionnal item"
You might want to consider using an opcode cache, if you can install extensions on your server ; for instance, I almost always work using APC (see also PHP manual), which is quite easy to install, and really good for performances (it can sometimes divide by 2 the CPU load of a server ^^ )
Just as a sidenote : if Aptana can't handle 400 lines files, you should really think about using another IDE ^^
(Eclipse PDT is not bad if you have 2 GB of RAM -- eclipse-based, like Aptana, so shouldn't be too "new")
Personally, I like to include the files separately. If you include every class on every page, it just increases parsing overhead by processing lots of code that probably isn't even used on that page along with the associated overhead of reading the files from disk, etc.
It's negative in the sence that it requires more disk I/O. However, in a production stage you should use opcode cache anyway, and this will negate much of the negative impact.
On the positive side, you will achieve a better code structure, where each class belongs to a single file. This makes testing easier, and also allows you to auto-load classes on demand, thus reading only the necessary files.
I think your includes should generally only go one 'level' deep, unless you have a really good reason otherwise. What will happen is you will end up chasing down some issue and going on wild goose chases through include files, and you might even end up using stuff like "include_once" or "require_once", which is almost certainly a code smell.
Multiple includes are the best way of well organasing your code, i recommend it as well, but in some cases, ( as mine) only the first include that gets executed i dont know why im stuck with it
On a site where 90% of the pages use the same libraries, should you just load the libraries all the time or only load them when needed? The other pages would be ajax or simple pages that don't have any real functionality.
Also, should you only load the code when needed? If part way down a page you need a library, should you load it then or just load it at the top. Maybe it's possible it may never get there before of an error or wrong data. (Loading at the top makes it somewhat easier to understand, but may result in extra code not needed.)
I'm also wondering if I should make the libraries more specific so I'm not say loading the code to edit at the same time as viewing?
Basically, how much should I worry about loading code or not loading code?
I would always try to give a file, class, and method a single responsibility. Because of that, separating the displaying from the editing code could be a good idea in either case.
As for loading libraries, I believe that the performance loss of including non required libraries could be quite irrelevant in a lot of cases. However, include, require, include_once, and require_once are relatively slow as they (obviously) access the file system. If the libraries you do not use on each occasion are quite big and usually include a lot of different files themselves, removing unnecessary includes could help reducing the time spent there. Nonetheless, this cost could also be reduced drastically by using an efficient caching system.
Given you are on PHP5 and your libraries are nicely split up into classes, you could leverage PHP's auto loading functionality which includes required classes as the PHP script needs them. That would pretty effectively avoid a lot of non used code to be included.
Finally, if you make any of those changes which could affect your website's performance, run some benchmarks and profile the gain or loss in performance. That way, you do not run into the risk of doing some possibly cool optimization which just costs too much time to fully implement or even degrades performance.
Bear in mind that each script that is loaded gets parsed as PHP is compiled at run-time, so there is a penalty for loading unneeded scripts. This might be minor depending on your application structure and requirements, but there are cases which this is not the case.
There are two things you can do to negate such concerns:
Use __autoload to load your scripts as they are needed. This removes the need to maintain a long 'require' list of scripts and only loads what's needed for the current run.
Use APC as a byte-code cache to lower the cost of loading scripts. APC caches scripts in their compiled state and will do wonders for your application performance.
+1 Vote for the autoload technique.
The additional benefit of using autoload is it eliminates some of the potential for abusive code. If something fails, pop a back-trace and an "included_files" list and you get a list of places where the problem could come from.
This means you have less files to hunt through if somebody hides malicious code at the end of one of them, or designs something fruity.
I worked on a codebase once ( not mine ) where the presence of certain tokens in the URL caused unexpected behaviour, and because the code was horrible, it was a nightmare tracking the origin of the problem burried in the fact in one of the 200 included files one of them was rewriting the entire request and then calling "die"
The question was "how important".
Answer: it is NOT important at all. If you don't have a dozen servers running this app already, then this is probably early optimization, and as we all know, early optimization is the root of all evil.
In other words: don't even worry about it. There are a lot of other things to optimize speed before you should even consider this.