I have a PHP-file that is included by a lot of other PHP-scripts, which all use only a subset of the functions and variables defined in that included file. (I guess this is the usual case for most larger libaries.)
For this reason, in most cases only a small part of the included file is actually used and most of it simply ignored (unused functions, never referenced variables, etc.).
But AFAIK all recent versions of PHP come with the Zend-optimizer, which as far as I understand it, produces some kind of bytecode that is then used at runtime. It therefore should filter out all unused code, so even a huge number of unused functions would cause zero overhead at runtime.
Is this the case or is there a performance overhead for using large libraries in PHP?
From the PHP 5.5 change log of new features:
The Zend Optimiser+ opcode cache has been added to PHP as the new
OPcache extension. OPcache improves PHP performance by storing
precompiled script bytecode in shared memory, thereby removing the
need for PHP to load and parse scripts on each request.
What I understand from that statement is that every .php file, when converted into bytecode, will be saved into shared memory so that the conversion does not need be repeated per file. As we are no longer performing that step our processing time goes down.
This means that the uncalled functions and un-needed variables get declared and stored in the cache but never used.
is there a performance overhead for using large libraries in PHP?
The answer to that is almost always "yes". There have been numerous benchmarks that say that a library is slow, even when using OPCaching (such as APC or Zend Optimiser).
Related
I want to know if unused use statements in my class affect performance of my php website?
Does php include all classes in beginning or when need it? If second choice then I think it doesn't affect performance of my system.
For Example: Use statement 'DbConnector' is not used
use model\adapter\DbConnector;
No, the use statement does not provoke the the class be loaded (it does not even trigger an autoloader).
It just declares a short name for a class. I assume the cost in terms of CPU and RAM is in the order of a few CPU cycles and a few bytes.
Newer versions of PHP, PHP 7 and especially PHP 7.2, are very good at optimizing code when it's complied into byte code. Unsed use statements are just stripped away by the compiler and will not even execute. Therefore it should not have any impact whatsoever. The compiler might use a few more CPU cycles while parsing the file but if you use OPCache there will be no effect on performance. The file will only be loaded when they are needed.
Alternatively does it copy the compiled code from cache (APC) or load it from disk for each call.
The reason I am asking this is that I have a large data structure that I have initialized in a file. Now I worry about the performance of the script.
PHP is actually very efficient at dealing with large data-structures. It is, however, always going to store them in memory (which is not shared between calls). If it is large enough, you might want to consider buffering it piece by piece or storing it in a datastore of some sort. If your data file is 100MiB, you're going to be loading at least 100MiB plus the memory required by PHP with every call.
APC wont entirely help this situation either. When PHP loads initially (without APC), it will perform the following steps:
Read the entire file into memory
Lexing, it tokenizes the file into standard codes or "Lexicons" for the parser to read
Parsing, it then utilizes the tokens in the file to generate the required expressions for complication
Compiling, It takes the expressions and creates "opt-codes" similar to how Java "compiles"
Executing, the opt-codes are executed in the PHP runtime (data actually gets manipulated here)
You might have noticed that steps 1-4 are all redundant with multiple calls which is why compiled languages have a dedicated compiler to perform these steps and either a Runtime, VM, or OS to run the generated bytecode or binary on. APC actually tries to give PHP that same edge: by precompiling each file, it can then store the (typically smaller) precompiled, opt-code file into memory and access it when someone accesses the page.
The problem with your use-case is that this does absolutely nothing for literal data within a file. Data still must be declared and wont even be touched until step 5, which is why I am emphasizing the importance of perhaps using an external data store if you see a significant performance hit.
Please use a profile like XDebug or something similar to gain some more insight on what is actually slowing your script down (if at all) so you can make a more informed decision on where to go from here.
Is there a way to define constants that boot into memory when the PHP process starts on the server? If so, can it be done with arrays, classes, and functions as well?
Before people start listing the different ways of declaring things that will be available across pages and scopes: I'm not asking this from a coding convenience, but rather a performance perspective.
It seems like a waste to keep loading things that never change, from pages or databases etc, on every script execution. Being a server-side process, I would think PHP has some way to read things into memory once and have them always available.
What you are looking for is an opcode cache. Opcode caches work by storing the compiled contents of PHP files in shared memory, then using that data to short-circuit the standard code parsing process when the file is included/required in the future.
The canonical opcode cache at this point is the PHP opcache extension, but a number of other opcode caches exist, including APC and XCache.
Opcode caches do not cache data from databases. There are other extensions which you can use to assist in this process, though, such as APCu which stores them in shared memory, or memcached which stores them in an external process. None of this is automatic, though, as caching data from a database requires some application knowledge to know what is useful to cache, and to handle cache invalidation when you update the database.
In general php is a single treaded environment and it does not actually run constantly (unlike java). Php starts working only when receives a command to do so. Then it parses the code into opcode and eventually executes it. And that technically happens on every request (or CLI command).
However, there are several ways how you can cache the opcode with not much efforts with APC: http://www.php.net/manual/en/book.apc.php
That's basically all my question is, if I have php pages that have 5,000-10,000 lines of code for a certain purpose, in my case image upload management (cropping and such), would it slow down the rest of my documents to include them on each page that doesn't use them? Basic logic tells me it of course would, but at the same time I'm not an expert, so I don't know if php acts differently than I may understand.
include and require statements makes PHP also compile/interpret the files that you include. That does cost some computation but in 99 % of cases it won't matter... unless your site is very popular and saving that computation time is important. If that is the case, you can solve this very easily by using so called PHP Accelerators (like XCache or APC). These can be installed along with your PHP installation and cache in RAM all the compiled opcode from your php scripts. Improvements with this solution vary between 40 and 75 %.
There will be a slight slowdown as the unused functions (extra code) needs to be parsed and it would also take extra memory. Apart from that no other effect.
I hope this is not a completely stupid question. I have searched quite a bit for an answer, but I can't find (or recognise) one exactly on point.
I understand that functions in PHP are not parsed until actually run. Therefore, if I have a large class with many functions, only one of which requires a large include file, will I potentially save memory if I only include the "include file" within the function (as opposed to at the top of the class file)?
I presume that, even if this would save memory, it would only do so until such time as the function was called, after which the memory would not be released until the current script stopped running?
Many Thanks,
Rob
I love this saying: "Make it work and then, if needed, make it fast." -some good programmer?
In most cases you would probably be better off focusing on good OOP structure and application design then speed. If you server is using something like Zend Optimizer having all your methods in a single file won't make any difference since it is all pre-compiled and stored in memory.(It's more complicated then this but you get the idea)
You can also load all your include files when apache starts. Then all the functions are loaded in memory. You wouldn't want to do that while developing unless you like to restart Apache every time you make a code change. But when done on production servers it can make a huge difference. And if you really want to make things fast you can write the code in C++ and load it as a module for Apache.
But in the end... do you really need that speed?
Yes it will, but be sure that the function doesn't depend on any other functions included in the parent. The memory consumption is also dependent on a couple things, from the size of the file itself to the amount of virtual memory it requires with variable setting and proper garbage collection protocols.
If the function is inside a class, it's called a method, and it might depend on its class to extend another class.
Just some things to consider. Always include the bare minimum.
Don't save memory on such cases unless you really need it, save development time. Memory is usually cheap but development/supoort time isn't. Use php opcode cacher like eAccelerator or APC, it will increase speed of execution because all files will be pre-compiled and stored in memory.