Should I try to keep all helper functions in the same file (say, all in functions.php) at the cost of reading in unnecessary functions, or store functions in separate files where I'll only include files with functions I need, at the cost of the overhead for including more files? How big of an overhead is there to include separate helper files? I know for images like icons it's faster to join icons together in 1 image, but I'm not sure if the same applies here.
This completely depends on the project you're working on - sometimes the one approach may be faster, sometimes the other. But in general, just avoid making lots of global helper functions and put them in appropriate classes instead, as static helpers if need be. Then read up on autoloading and watch as PHP's magic solves the problem all in one go for you - loading and parsing the files automatically as you need them.
If you also use PHP 5.5+ (or an older version with an opcache-like extension) the code will even be precompiled, lowering overhead even further.
Generally speaking some more - once you're starting to worry about the parsing overhead of your code you're usually guilty of premature optimization. In a world where nearly all webservers have quad core hyperthreaded multigigahertz processors and are backed by RAID SATA storage, loading an extra file isn't going to be a realistic problem. Find the real bottlenecks when all the code is done, and spend your optimization time there.
Related
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
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.
I'm building a PHP site, but for now the only PHP I'm using is a half-dozen or so includes on certain pages. (I will probably use some database queries eventually.)
Are simple include() statements a concern for speed or scaling, as opposed to static HTML? What kinds of things tend to cause a site to bog down?
Certainly include() is slower than static pages. However, with modern systems you're not likely to see this as a bottleneck for a long time - if ever. The benefits of using includes to keep common parts of your site up to date outweigh the tiny performance hit, in my opinion (having different navigation on one page because you forgot to update it leads to a bad user experience, and thus bad feelings about your site/company/whatever).
Using caching will really not help either - caching code is going to be slower than just an include(). The only time caching will benefit you is if you're doing computationally-intensive calculations (very rare, on web pages), or grabbing data from a database.
Sounds like you are participating in a bit of premature optimization. If the application is not built, while performance concerns are good to be aware of, your primary concern should be getting the app written.
Includes are a fact of life. Don't worry about number, worry about keeping your code well organized (PEAR folder structure is a lovely thing, if you don't know what I'm talking about look at the structure of the Zend Framework class files).
Focus on getting the application written with a reasonable amount of abstraction. Group all of your DB calls into a class (or classes) so that you minimize code duplication (KISS principles and all) and when it comes time to refactor and optimize your queries they are centrally located. Also get started on some unit testing to prevent regression.
Once the application is up and running, don't ask us what is faster or better since it depends on each application what your bottleneck will be. It may turn out that even though you have lots of includes, your loops are eating up your time, or whatever. Use XDebug and profile your code once its up and running. Look for the segments of code that are eating up a disproportionate amount of time then refactor. If you focus too much now on the performance hit between include and include_once you'll end up chasing a ghost when those curl requests running in sync are eating your breakfast.
Though in the mean time, the best suggestions are look through the php.net manual and make sure if there's a built in function doing something you are trying to do, use it! PHP's C-based extensions will always be faster than any PHP code that you could write, and you'll be surprised how much of what you are trying to do is done already.
But again, I cannot stress this enough, premature optimization is BAD!!! Just get your application up off the ground with good levels of abstraction, profile it, then fix what actually is eating up your time rather than fixing what you think might eat up your time.
Strictly speaking, straight HTML will always serve faster than a server-side approach since the server doesn't have to do any interpretation of the code.
To answer the bigger question, there are a number of things that will cause your site to bog down; there's just no specific threshold for when your code is causing the problem vs. PHP. (keep in mind that many of Yahoo's sites are PHP-driven, so don't think that PHP can't scale).
One thing I've noticed is that the PHP-driven sites that are the slowest are the ones that include more than is necessary to display a specific page. OSCommerce (oscommerce.com) is one of the most popular PHP-driven shopping carts. It has a bad habit, however, of including all of their core functionality (just in case it's needed) on every single page. So even if you don't need to display an 'info box', the function is loaded.
On the other hand, there are many PHP frameworks out there (such as CakePHP, Symfony, and CodeIgniter) that take a 'load it as you need it' approach.
I would advise the following:
Don't include more functionality than you need for a specific page
Keep base functions separate (use an MVC approach when possible)
Use require_once instead of include if you think you'll have nested includes (e.g. page A includes file B which includes file C). This will avoid including the same file more than once. It will also stop the process if a file can't be found; thus helping your troubleshooting process ;)
Cache static pages as HTML if possible - to avoid having to reparse when things don't change
Nah includes are fine, nothing to worry about there.
You might want to think about tweaking your caching headers a bit at some point, but unless you're getting significant hits it should be no problem. Assuming this is all static data, you could even consider converting the whole site to static HTML (easiest way: write a script that grabs every page via the webserver and dumps it out in a matching dir structure)
Most web applications are limited by the speed of their database (or whatever their external storage is, but 9/10 times that'll be a database), the application code is rarely cause for concern, and it doesn't sound like you're doing anything you need to worry about yet.
Before you make any long-lasting decisions about how to structure the code for your site, I would recommend that you do some reading on the Model-View-Controller design pattern. While there are others this one appears to be gaining a great deal of ground in web development circles and certainly will be around for a while. You might want to take a look at some of the other design patterns suggested by Martin Fowler in his Patterns of Enterprise Application Architecture before making any final decisions about what sort of design will best fit your needs.
Depending on the size and scope of your project, you may want to go with a ready-made framework for PHP like Zend Framework or PHP On Trax or you may decide to build your own solution.
Specifically regarding the rendering of HTML content I would strongly recommend that you use some form of templating in order to keep your business logic separate from your display logic. I've found that this one simple rule in my development has saved me hours of work when one or the other needed to be changed. I've used http://www.smarty.net/">Smarty and I know that most of the frameworks out there either have a template system of their own or provide a plug-in architecture that allows you to use your own preferred method. As you look at possible solutions, I would recommend that you look for one that is capable of creating cached versions.
Lastly, if you're concerned about speed on the back-end then I would highly recommend that you look at ways to minimize your calls your back-end data store (whether it be a database or just system files). Try to avoid loading and rendering too much content (say a large report stored in a table that contains hundreds of records) all at once. If possible look for ways to make the user interface load smaller bits of data at a time.
And if you're specifically concerned about the actual load time of your html content and its CSS, Javascript or other dependencies I would recommend that you review these suggestions from the guys at Yahoo!.
To add on what JayTee mentioned - loading functionality when you need it. If you're not using any of the frameworks that do this automatically, you might want to look into the __autoload() functionality that was introduced in PHP5 - basically, your own logic can be invoked when you instantiate a particular class if it's not already loaded. This gives you a chance to include() a file that defines that class on-demand.
The biggest thing you can do to speed up your application is to use an Opcode cache, like APC. There's an excellent list and description available on Wikipedia.
As far as simple includes are concerned, be careful not to include too many files on each request as the disk I/O can cause your application not to scale well. A few dozen includes should be fine, but it's generally a good idea to package your most commonly included files into a single script so you only have one include. The cost in memory of having a few classes here and there you don't need loaded will be better than the cost of disk I/O for including hundreds of smaller files.