Re: [Coding Standards] Loading all files at once

From: Date: Thu, 12 Jul 2007 15:26:04 +0000
Subject: Re: [Coding Standards] Loading all files at once
References: 1 2 3 4 5 6 7 8 9 10 11 12  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-47434@lists.php.net to get a copy of this message
On Jul 12, 2007, at 10:22 AM, Philippe Jausions 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.
and it of course does not fit the unzip and go crowd. Speaking of unzip and go, we should teach the package command to do all possible file rearranging before the tar to further ease the life of unzip and go people without loosing the ability to move files into different locations than where they are in CVS.
If the 'pear package' command could create allfiles.php, a build tool could then later strip out the require_once commands from the various files. This would then suit those who want unzip-and-go (as allfiles.php is present), those who want to keep it in the include_path (require_once calls that utilize the include_path for resolution), and those who need optimization (build tool to strip out *_once calls). Keep the standards as they are, but have tools available to suit the various target audiences.
Just one note, a build tool would only be able to clean up require_once, if the way require_once is used is strictly standardized to allow such stripping. There are far many different ways some of the current factory methods work, including using include_once, and custom findFile(), classExists() methods and the like.
Which begins to make an argument for having a standard PEAR_Loader class. -- 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>

« previous php.pear.dev (#47434) next »