Re: [Coding Standards] Loading all files at once

On 7/9/07, Paul M Jones <pmjones@ciaweb.net> wrote:

On Jul 9, 2007, at 5:26 PM, Joshua Eichorn wrote: Paul M Jones wrote:

The proposed coding standard states:

Loading all files at once

... I'm going to stop commenting now since i've noticed that I'm half of the emails in this thread, and thats generally not healthy for the discussion or the community. I don't know if it's healthy for the community or not, but it does indicate to me that the problem (and the proposed solution) are not well-understood by others here (including me). It may be that "allfiles" *is* the right solution ... but to exactly what set of problems, well, I'm still not clear on that, and it appears I'm not alone.

PHP's performances and poor require_* performances (See below)

At worst, it seems like that portion of the standard should be marked as "tentative" or "subject to further discussion".

In some previous projects I have worked on (Over 20M users), having multiple files and using require_once into many many files is a problem. let's say 15 interfaces (low count) and 15 classes using the interfaces, you need to require_once somefile in the interfaces sometimes as well. That's when the problem occurs.. In order to optimize you'll go with putting all the files in one require (furthermore some projects (like doctrine) aggregate all the files into one, and cache this file in order to remove the includes, etc and cache this file..) Anyways, the point is, many people from some PHP company claim to say that PHP is not slower using many require_once and most benchmarks made are not made using real world load, they are simple ab tests and not intensive and extensive stress-tests. Saying that PHP is *not really* slower when using many different files (require_once in many places and subsequent files) is totally false. It is slower and very much slower, but not only with 2 levels of requires but when you start going to 7, 8, 9, etc levels of requires: ex: if you have 5-6 classes that are requiring some interfaces that are requiring a few other interfaces, and those same 5-6 classes are requiring packages as such as Validate, which is requiring some external validate_ca that requires validate_isbn and also requires MDB2 that requires Manager driver and requires Datatype driver, etc.. this will get extremely slow compared that if you put all of those into one load file or in our case "allfiles.php" the idea is to be able to cache the load file easily and access the classes well cached. I would actually like to spend some time creating real valid benchmarks using real complex applications and demonstrate the benefit of the allfiles.php file in a real-world application. however I currently have no time to accomplish such task, however if someone would like to make some, I'd be happy to direct and assist them.

-- Paul M. Jones <http://paul-m-jones.com> Solar: Simple Object Library and Application Repository for PHP5. <http://solarphp.com> Join the Solar community wiki! <http://solarphp.org> Savant: The simple, elegant, and powerful solution for templates in PHP. <http://phpsavant.com> -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

However that allfiles.php per packages isn't even the best to do, but for large packages, that will already be a good gain of performance (and this is not something only *geeks* should want but anyone that is listening to their customers :P) - And yes, i'm expecting to see such answers as: 1) If you are optimizing at this level there's something else wrong 2) That's not true. 3) it's for personal use 4) I don't use pear for commercial uses 5) I don't know why but I'll complain ;_) -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18