Basics of PHP opcode cache

Question

Currently on a very large project that I do not plan to re-use for another site, I have the site's name hardcoded into the files everywhere. Now, if I were ever to change the site name it would take a lot of effort to change that everywhere. I know the obvious solution is to just store the name as a variable or a constant, but I guess you could call it my micro-optimizing way of thinking: I always figured it would be one less thing PHP has to parse. I do realize it won't make much difference, but I just wanted to know whether using an opcode cache like APC would mean that PHP wouldn't even have to re-parse that?

Answer 1

Really : you shouldn't care about anything like that.

Any difference in configuration will means much more difference (for instance, the apc.stat option, for APC, can have quite an impact on the load of your server -- and anything like DB queries you do will have hundreds of time more impact)

Here, what probably matters is maintenability :

• does it get you any benefit (except from that nano-optimisation) to have the site name not hard-coded ?
• does it get you any benefit to have it hard-coded (same exception) ?

If the answer is "no" in either case, and your application works... well, that's what matters !

If you have time to spend with that kind of less than micro optimisations, it would probably be better spent going through your application code with a profiler, going through your DB queries, the number of HTTP requests you are doing to fetch static JS/CSS/images, upgrading PHP or modifying your code so it can run on PHP 5.3 (as PHP 5.3 comes with some optimisations over 5.2), ...

All those will most probably get you a higher gain ;-)

Edit after the comment :

Basically, when a PHP file is loaded :

• the file is read from disk
• it's parsed and compiled to opcode
• the opcodes are executed

With an opcode cache :

• if there is a place in RAM containing the opcodes, those are loaded from RAM (is, no reading of a file, nor parsing/compiling)
  • if not, see the steps before -- just add a "store the opcodes to RAM" before execution, for the next request
• and the opcodes are executed

The apc.stat option defines whether APC should examine the last modification date/time of a file to decide between using the opcodes from RAM, or re-compiling the file if it is more recent that the opcodes in RAM.

Disabling this option means :

• files are not checked on disk => faster, and uses less resources
  • For instance, I've seen a drop of CPU-load, between 10 and 15%, when disabling this option on a quite loaded server
• but as there is no check for modification, if you want a modification to be taken into account, you have to clear the cache

Still, what I said is true : there are probably lots of things you can optimise that will mean more important gain than a simple "should I use hard-coded values" versus "should I use constants/variables".

Answer 2

this is wat exactly happens.. without going into token level detail...

PHP is a scripting language, which most people take to mean that it is not compiled. While this is true in the traditional sense in that we are not calling a gcc or javac; instead we are compiling every time the script is requested. In fact, the PHP and Java compilation life cycles are pretty similar, because they both compile to an intermediary instruction set (opcodes, or bytecodes) which are then run in a virtual machine (Zend VM or JVM).

The parsing and compilation phases is slow. When we add an opcache, we short-circuit this process by storing the result of the parsing and compilation phases, leaving just the execution to run dynamically as always. In effect, we are closer to the Java life-cycle now; with the main differences being that we saved to shared memory instead of a file, and can automatically re-compile if changes occur to the script.

Use the opcode cache. It will give you more performance boost than any micro-optimizations possibly can. Additionally, when using Zend OpCache, a lot of optimizations are done for you (e.g. switching $i++ to ++$i when the return value isn’t used).

Using an opcode cache should not be optional anymore, it will enable you to get more performance from your hardware with very little effort.