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.
Related
I declare 100 functions, but I don't actually call any of them. Will having so many functions defined affect loading time?
Does PHP process these functions before they are called?
Yes, php parses all functions on the run, and checks possible syntax errors , (though it does not execute them all this time) and registers their name as a symbol. When you call any of the functions, php searches for the function in the registered symbol table for function name and then executes that function.
So, better to use functions of your purpose only as it will increase the size of symbol table.
Just to be clear, even having hundreds of unused classes and functions is not going to make much difference to the performance of your program. Some difference, yes maybe, but not much. Improving the code that is being run will make a bigger difference. Don't worry about optimising for language mechanics until you've got your own code perfect. The key to performance optimisation is to tackle the biggest problems first, and the biggest problems are very rarely caused by subtle language quirks.
If you do want to minimise the effect of loading too much code that isn't going to be used, the best way to do this is to use PHP's autoloading mechanism.
This probably means you should also write your code as classes rather than stand-alone functions, but that's a good thing to do anyway.
Using an autoloader means that you can let PHP do the work of loading the code it needs when it needs it. If you don't use a particular class, then it won't be loaded, but on the other hand it will be there when you need it without you having to do an include() or anything like that.
This setup is really powerful and eliminates any worries about having too much code loaded, even if you're using a massive framework library.
Autoloading is too big a topic for me to explain in enough detail in an answer here, but there are plenty of resources on the web to teach it. Alternatively, use an existing one -- pretty much all frameworks have an autoloader system built-in, so if you're using any kind of modern PHP framework, you should be able to use theirs.
I designed a PHP 5.5+ framework comprised of more than 750 different classes to make both web applications and websites.
I would like to, ideally, be able to reduce its size by producing a version of itself containing just the bare essential files and resources needed for a given project (whether it's a website or a web application).
What I want to do is to be able to:
reduce the amount of traits, classes, constants and functions to the bare essential per project
compress the code files to achieve a lesser deployment size and faster execution (if possible)
So far, I've got the second part completed. But the most important part is the first, and that's where I'm having problems. I have a function making use of get_declared_classes() and get_declared_traits(), get_defined_constants() and get_defined_functions() to get the full list of user-defined classes, traits, functions and constants. But it gives me pretty much EVERYTHING and that's not what I want.
Is there a way to get all defined classes, functions and constants (no need for traits as I could run class_uses() on every class and get the list of traits in use by that class) for a single given script?
I know there's the token_get_all() function but I tried it with no luck (or maybe it's I'm using it the wrong way).
Any hint? Any help would be greatly appreciated :)
You can use PHP Parser for this. It constructs abstract syntax trees based on the files you supply to it. Then you can analyze its output for each file, and produce a report usable to you.
Other than that, you can use token_get_all() approach you've mentioned already, and write a small parser yourself. Depending on your project, this might be easier or more difficult. For example, do you use a lot of new X() constructs, or do you tend to pass dependencies via constructors?
Unfortunately, these are about the only viable choices you have, since PHP is dynamically typed language.
If you use dependency injection, however, you might want to take a look at your DI framework's internal cache files, which often contain such dependency maps. If you don't use such framework, I recommend to start doing this, especially since your project is big and that's where dependency injection excels at. PHP-DI, one of such frameworks, proved to be successful in some of my middle-size projects (25k SLOC).
Who knows? Maybe refactoring your project to use DI will let you accomplish the task you want without even getting to know all the dependencies. One thing I'm sure of is that it will help you maintain it.
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
I have this problem that is really causing me headeches whenever i'm designing my apps in php: I don't know if i should create separete files for each function(e.g.: functions for validating specific forms).
OK, one would possibily argue that this makes no sense because I would have to include each file separetly and this would result in a more slow application maybe?
But I still think it does make sense since for one pageload i doubt that other functions would be used by the script at all, so they must be loaded just for nothing? besides, i don't have to include each function-file manually if the system i design does this dinamically (parsing url vars or such) for me, that is, loading function(-files) exactly when needed. What do you think?
The overhead in file includes is minimal, you shouldn't have to worry about it really, considering caching and other things. Of It's more about how you can keep yourself organized and find your stuff quickly.
Honestly, I rarely use functions, I use classes. The rule is usually to have a class per file. But I also have a toolbox file that contains all my global functions.
Are you using OO? If so, then you should definitely keep it one class per file, and name the files intelligently...
class Page {
...
}
should be findable somewhere like classes/Page.php or includes/Page.class.php or similar.
If you just have a bunch of global functions, you should group them in files, e.g. includes/functions/general.php.
To elaborate, your functions folder may have...
array.php
string.php
form_validation.php
request.php
general.php
html.php
If you are organising your files like this, a better idea is to use a class and make the functions static, e.g. string::isAlphaNum($str). This is a better idea because it only introduces one new term to your global namespace, instead of a bunch of them needlessly.
If you are using PHP 5.3, you could also look at namespaces.
You should just make sure that you have APC, xCache or eAccelerator installed. All of them provide cache for compiled PHP bytecode.
It means that once the file has been included it will be stored in memory and ready to use by feature requests. There won't be any need to include files.
You will almost certainly see a more significant performance hit through increased disk I/O reads on (many) multiple file includes than for smaller set of files with many functions.
For automatic file includes, wrap functions into suitable classes and use spl_autoload to let PHP handle the include process.
I'm trying to find the best pragmatic approach to import functions on the fly... let me explain.
Say I have a directory called functions which has these files:
array_select.func.php
stat_mediam.func.php
stat_mean.func.php
.....
I would like to: load each individual file (which has a function defined inside) and use it just like an internal php function.. such as array_pop(), array_shift(), etc.
Once I stumbled on a tutorial (which I can't find again now) that compiled user defined functions as part of a PHP installation.. Although that's not a very good solution because on shared/reseller hosting you can't recompile the PHP installation.
I don't want to have conflicts with future versions of PHP / other extensions, i.e. if a function named X by me, is suddenly part of the internal php functions (even though it might not have the same functionality per se) I don't want PHP to throw a fatal error because of this and fail miserably.
So the best method that I can think of is to check if a function is defined, using function_exists(), if so throw a notice so that it's easy to track in the log files, otherwise define the function. However that will probably translate to having a lot of include/require statement in other files where I need such a function, which I don't really like. Or possibly, read the directory and loop over each *.func.php file and include_once. Though I find this a bit ugly.
The question is, have you ever stumbled upon some source code which handled such a case? How was it implemented? Did you ever do something similar? I need as much ideas as possible! :)
One way you could pull something like this off is to put those functions into classes and then set up an __autoload function. If you are against wrapping the functions in classes than this solution probably won't apply to you. Personally I like it because it allows me to namespace my functions and share private methods between them.
First you set up your autoload function similar to this. You'll want to adjust the naming convention to fit your own style, and probably introduce some error handling, but this is just to get the basic idea across.
function __autoload($class_name){
require_once(strtolower("library/$class_name.class.php"));
}
Then anywhere in your code regardless of scope you can do something like this.
arrayFunctions::doStuff($myArray);
PHP will automatically try to include "library/arrayFunctions.class.php" and look for a method called "doStuff" in the arrayFunctions class.
I have issues with this idea. Hitting the file system to include a single function is very expensive in the terms of it lowering your max possible requests per second.
It's generally much better to load/parse five functions in a single file (static class?) and only use two of them (one stat call) rather than load two files for two functions (two stat calls).
Which obviously becomes even worse when you need all five functions.
To automatically load stuff when need, put your functions in classes and use autoloading.
For the name conflict, use namespaces (if you have PHP 5.3).