Published 2005-03-17 22:43:36

I noticed a small thread on pear-dev about require_once, the concept that having require_once to lazy load files, is slowing things down seems to crop up every so often.

The crux of the issue appears to be the impression that lazy loading is slowing things down somehow, and that doing something like this may improve performance.

class_exists('PEAR') or require_once 'PEAR.php';
Or even worse, thinking about using __autoload magic..

In early versions of PHP4.3, and before, each require_once call had to do quite a bit of work to determine if a file had already been included.

It made the assumption that you might have changed the include path, and therefore, the file you where requesting might actually not have been loaded. So each call went through your every path in your include_path, made sure each part of the directory existed, and the tried to open the file, this resulted in quite a few stat calls (via realpath), as well as a few opens.

How much this was slowing things down was never really examined in detail, (although from what I remember Rasmus indicated that Y! had done a few patches to address this), but the existance of this patch and the general assumtion was that stat and open where relatively expensive made the situation sound kind of serious.

After considering the issue, a few of the core developers (Andi and Rasmus I think) added a stat cache feature. So rather than stat'ing the whole path on each require, it looked it up in a cache. The result can be seen by running this

strace php4 -r 'require_once "PEAR.php"; require_once "PEAR.php";' 2>&1 \ 
| grep -E '(stat|open|close|read)' | tail -30
As you would see from the output, what happens now is that the second call to require_once, calls open once on each possible location of the file (normally something like ./PEAR.php and /usr/share/pear/PEAR.php)

This should be pretty efficient, as long as you dont modify the path during the your php script (like move a directory or something).

However, as the discussion this week shows, this questionable performance issue still hasnt disappeared. So I got bored today and wondered what would be involved in making it even more efficient. (basically optimizing the second call to any [require|include]_once)

This is the result, not a working patch, more just a concept.

The idea being that assuming most people dont change the include path that often (probably only once when the app starts), then caching the strings that get sent to [require|include][_once] and testing them before doing any file operations could basically kill this kind of talk. The concept and code are simple enough that it shouldnt have too many knock on effects, and shouldnt use up too many resources to save a few open()'s..

The question is though, is if this is really an issue or just the impression of an issue....

Mentioned By: : include_once Wrapper Class | Pure PHP (335 referals) : php require_once (95 referals) : require_once performance (87 referals) : april (83 referals) : PHP News, Views, and Community... (75 referals) : includeWrapper.class.php (69 referals) : php require_once performance (64 referals) : Planet PHP Japan (57 referals) : PRADO Component Framework for PHP 5 - Forum (54 referals) : march (52 referals) : require_once (52 referals) : PHP ¬ - [php] PHP ˡ: empty($hoge) and $hoge = 'huni'; (36 referals) : Pure PHP | PHP unconventional (32 referals) : december (31 referals) : Planet PHP (27 referals) : php require_once path (27 referals) : require_once 'PEAR.php'; (27 referals) : ϲùʴ - ¹˵includeonce࣬ʵЧң - (26 referals) : Re: [PHP-DEV] __autoload() enhancement (26 referals) :  International PHP Magazine - Cutting-Edge Technologies for Web Professionals (23 referals)


__autoload() is your friend
I disagree on the question if __autoload() is useful or not.

I find __autoload() to be a great tool that complements how PEAR may be able to work. Using __autoload() you gain more control over what code gets included where. �t also allows users from getting rid of the include_path directive which we rely on to give the user a little more control today.

Overall I would say __autoload() is no more magic than the include_path directive. However it is more flexible and affects performance less.
#0 - Lukas ( Link) on 2005-03-17 23:18:14 Delete Comment
class_exists is useful
Checking if the class exists before including it is useful from a customization standpoint, since it allows you to hack up the PEAR class and include it before the other code, without having to create some crazy include path.

I'm not sure about __autoload() for PEAR but its made sense for all the php5 apps i've written so as long as its easy to override there shouldn't be any problems.
#1 - Joshua Eichorn ( Link) on 2005-03-18 00:27:48 Delete Comment
Maybe a include_once Wrapper Class?
This is good for the inclusion of classes, but what about othre code?

You can also use some kind of wrapper function, for expample this wrapper class.


#2 - Pure-PHP ( Link) on 2005-03-18 06:07:31 Delete Comment

Add Your Comment

Follow us on