Re: [Coding Standards] Loading all files at once

A recent blog entry got me to thinking: why is the performance of require/include_once being touted as a necessary optimization at all? Typically, loading up the various library files necessary for your application is but a small fraction of the total processing time; in most applications where you need to worry about performance, you're needing to think about optimizing your database calls, web service calls, etc. -- not the amount of time you spend loading files. On the flip side, as a number of people have already indicated, environments with opcode caches are *not* the only environments around. Many use shared hosting environments, where opcode caches are not installed or cannot be installed; and in most development environments, you will typically *not* have opcode caching turned on to prevent a stale cache from masking changes to your code. A solution such as allfiles.php would be introducing unnecessary and unwanted overhead, as extra, unnecessary files are loaded on each request. What I'm seeing is a solution that caters specifically to high availability production environments at the expense of others. On 7/13/07, till <klimpong@gmail.com> wrote:

On 7/13/07, Philippe Jausions <Philippe.Jausions@11abacus.com> wrote: Lukas Kahwe Smith wrote:

Matthew Weier O'Phinney wrote:

On 7/12/07, Lukas Kahwe Smith <mls@pooteeweet.org> wrote:

* It's hard to verify that require_once is or is not the bottleneck, as results vary based on environment and methodology * Regardless, the performance gain, if any, is not huge * Many are upset with the proposal, on many grounds including: * seems like a rewrite of PHP (!class_exists() hack) that could lead

     to a situation similar to the PEAR::isError() situation (i.e., if
     PHP changes to be more performant or correct the situation, new
     standards and changes would need to be made, whereas using
     existing PHP functionality would not)

I do not think that the impact is debatable at all to the "speed freak" faction. Modification of code at install time is not the way to go. It will cause all sorts of uncertainties during deployment

Certainly, 15% is a sufficient enough gain to warrant making a change. However, whether or not this should be the job of PEAR instead of a build tool is debatable. Build tools are much better suited for this.

I very much disagree. If we modify code at install time, it will be a maintenance nightmare, things will stop working as users copy around code. Its a recipe for desaster since the changes are subtle. I was all for exploring some auto E_STRICT conversion tool because the changes would be super obvious and there was no reasonable way to do it back then. I do not see this case here. Furthermore there are tricky code constructs for loading drivers in many of our modules. These you will not be able to adapt with an installer, unless we really figure out a standardized way of doing those. regards, Lukas

I think a very simple way to do exactly this is: try {

    PEAR2_Load::loadClass($className);
    $instance = new $className();

catch ($e PEAR2_Load_ClassNotFoundException) {

    // Attempt another fall back, driver

} the try block is of course optional, but for those package that can't let a driver class not exists, the catch is simple. This way we get rid of all the different implementations of factory methods, and give even more control back to the user (i.e. why not let the exception bubble up and let the application take care of reporting the error or choosing a different driver.) This makes a no brainer to comment out the PEAR2_Load::loadClass() call, and it doesn't break the package. It doesn't even change the line count for easier debugging! I tried to follow those threads as much as possible - but I am wondering. Are we discussing speed issues here or more _intuitive_ code? From what I can tell we all know how to include code - everyone has a personal preference and arguments in favour of it, and against the others. But I am not sure if the different methods are discussed in terms of performance or what is easier to work with for people new to PEAR. Cheers, Till

-- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/