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
Related
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
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.
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 have main php-file with main class.
Also in this class i do
require_once("func.php");
which has many useful functions for my site.
Size of func.php is very big, because there is many functions for different actions on different pages. But I include it on every page, because including called by main class.
What I need to do for optimizing it?
Rewrite func.php to OOP and use in main class something like "$funcs->my_func()"? Will I won some performance? Functions which wasnt called would not occupy memory and CPU time?
Or I must rewrite func.php to many files and call each on specified page?
For example: for "about.php" I will include "about_func.php" with needed functions. But it isnt comfortable I think...
Please, help me :)
And sorry for my eng :)
How big is func.php? Are you sure the size is a problem.
This seems like a performance/optimization question at heart. Are you sure that optimization is warranted? Have you measured your page's performance and proved that including this big function file is to blame for its slowness?
I suggest you answer 1 & 2 to yourself before continuing. If the motivation for your question is cleaner design and modularization, then yes, I would agree that splitting a bug "utils" file into smaller files that share a responsibility or a general area of relevance is a good idea. If, on the other hand, this is a case of premature optimization, then you'd be better off leaving poor "func.php" along (hey, sometimes it's ok to have a big common utils file, as long as it's not hurting you).
Split it into oop classes and use the __autoload function of PHP5: http://www.php.net/manual/en/language.oop5.autoload.php
This wil load the classes only when needed and you don't have to worry about including all neccessary files. It won't give you any performance benefit but it's easier to manage smaller files for one purpose than a big one with several functions which are not dependent on each other.
Do you have a PHP accelerator enabled?
Zend Optimizer
eAccelerator
APC
Because they keep a "compiled" version of func.php in memory which should speed things up, without any code modifications.
Although I recommend OOP, it's not because of performance reasons.
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.