Asked  7 Months ago    Answers:  5   Viewed   37 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.

Wednesday, March 31, 2021
answered 7 Months ago

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 stackoverflow 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.

Wednesday, March 31, 2021
answered 7 Months ago

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.


Wednesday, March 31, 2021
answered 7 Months ago

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.

Saturday, May 29, 2021
answered 5 Months ago

There seems to still be confusion about this topic, however in most cases it comes down to ease vs performance.

A good mailing list thread to read would be this one on Zend Frameworks mailing list:

Now, the correlation is here because if you inherit from not-yet-defined class, you might rely on autoload to define it (though you might also rely on include), and actually the presence of the autoload facility may encourage you to use such inheritance. But this is not the autoload which brings trouble (see after Ramus' "it's not just autoload" in the blog for some examples of troublesome things). So the right phrase would be "people which tend to rely on autoload tend also to use code which defies compile-time binding". Which can't be seen as autoload fault, of course, and just avoiding autoload won't help a bit with that - you would also have to rewrite your code so that compile-time binding could happen. And it has nothing to do with uses of autoload with "new", for example.

As for the slowdown from the effects described above - i.e., absence of the compile-time binding - the code indeed becomes a bit slower and such code can lead in some obscure cases to some trouble to opcode caches (not in the autoload cases - but in cases where classes are defined inside conditions, or, God forbid, different definition is created depending on condition) - but it has next to nothing to do with using autoload by itself. The amount of slowdown, however, seem to be greatly exagerrated by people - it is nothing (and I repeat to be clear - NOTHING) compared to the performance benefit given by the opcode cache due to the absence of the disk operations and compilation stage. You could probably compose an artificial benchmark that would show some significant slowdown, but I do not believe any real application would even notice.


Friday, July 30, 2021
Desmond Hume
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :