Viewed   76 times
      $show_value   = 123;
      echo 'sing_quote'.$show_value;
      echo "double_quote{$show_value}";


Its opcode is:

1: <?php
2: $show_value   = 123;
        0  ASSIGN              !0, 123
3: echo 'sing_quote'.$show_value;
        1  CONCAT              'sing_quote', !0 =>RES[~1]     
        2  ECHO                ~1
4: echo "double_quote{$show_value}";
        3  ADD_STRING          'double_quote' =>RES[~2]     
        4  ADD_VAR             ~2, !0 =>RES[~2]     
        5  ECHO                ~2
        6  RETURN              1



Check out the Vulcan Logic Disassembler PECL extension - see author's home page for more info.

The Vulcan Logic Disassembler hooks into the Zend Engine and dumps all the opcodes (execution units) of a script. It was written as as a beginning of an encoder, but I never got the time for that. It can be used to see what is going on in the Zend Engine.

Once installed, you can use it like this:

php -d -d vld.execute=0 -f yourscript.php

See also this interesting blog post on opcode extraction, and the PHP manual page listing the available opcodes.

Friday, October 28, 2022

(Disclaimer : I only know APC)

What an opcode cache do is :

  • when a file is included/required, it take the full path to that file
  • check if the opcodes corresponding to that file are already in RAM (in opcode cache)
    • if yes, return those opcode so they are executed
    • if no, load the file and compile it to opcodes ; and store opcodes in cache.

The important point, here, is the entry point : the full path to the file.

What autoloading generally do is :

  • get the name of a class
  • transform it to the name of a file
  • include/require that file

So, the informations that are relevant for the opcode cache (full path to the file, and the fact that it is included/required) are still here.

In consequence, autoload shouldn't bring any trouble with op code caching.

(And, when using APC, it doesn't, as far as I can tell)

Thursday, October 20, 2022

For starters, both calls (require_once and include_once) double-check if a file has not been included before.

So the way they both achieve this is by searching the file in all available paths and by essentially checking if it hasn't been in the mix before etc..

In the background what happens is that they evaluate all the different options (e.g. multiple include_path's, etc.) and then by creating the realpath from this abreviated form they create a unique identifier. There is only one and the same path - not two.

This is already not the fastest process on the planet and generally happens on each request with PHP. Then add another expensive operation which is the stat when it creates what I called the realpath (realpath, because it's sort of what realpath() does) to check if the file exists.

Correct me if I am wrong, but APC has optimizations especially for this case.

So anyway - now on to the difference between require_once and include_once, which is that require_once evaluates the file (for low-level parse errors, etc.) when it includes it. This is an additional check which you can get rid of if you have enough QA in place that a parse error can never sneak into an include.

It's just tricky to find otherwise. :-)

(Something to consider: You could develop with require_once and replace all calls with include_once when you deploy.)

As for an opcode cache - I'd recommend APC. It's been discussed on before. Personally, I am/we are using it for a while (we handle roughly 100k visitors/day with 3 frontends and 1 backend) and we are very happy. APC is also optimized for the require_once/include_once madness.

A pretty cool side-effect is that APC also allows you to store PHP variables in memory - sort of persistant, etc..

A couple additional pointers:

  1. A lot of people claim to speed up any application with __autoload.
  2. With an opcode cache, avoid conditional require_once/include_once (e.g. in loops or in control-flow).
  3. Some people say that /absolute/path/to/file.php in include_ or require_once is faster than relying on the include_path.
  4. The order of the paths in your include_path matters as well.

Hope that helps.

Monday, October 17, 2022

To get the list of PHP processes see this question:

How to get list of running php scripts using PHP exec()?

Another option is that you can acquire a lock of the file and then check it before running: for example:

$thisfilepath = $_SERVER['SCRIPT_FILENAME'];
$thisfilepath = fopen($thisfilepath,'r');
if (!flock($thisfilepath,LOCK_EX | LOCK_NB))
  customlogfunctionandemail("File is Locked");
elseif(flock($thisfilepath,LOCK_EX | LOCK_NB)) // Acquire Lock
  // Write your code

 // Unlock before finish
 flock($thisfilepath,LOCK_UN);  // Unlock the file and Exit
 customlogfunctionandemail("Process completed. File is unlocked");

Basically in the above example you are first checking if the file is locked or not and if it is not locked (means process is completed) you can acquire lock and begin your code.


Sunday, October 9, 2022

You can change:

if ($_SERVER["HTTPS"] == "on") {$pageURL .= "s";}


if (array_key_exists('HTTPS', $_SERVER) && $_SERVER["HTTPS"] == "on") {$pageURL .= "s";}

array_key_exists returns a boolean. Since I check it first and use && the if statement will exit before checking the value of $_SERVER["HTTPS"] if it doesn't exist.

Monday, September 12, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :