Re: [Coding Standards] Loading all files at once
| From: | Matthew Weier O'Phinney | Date: | Wed, 11 Jul 2007 19:16:35 +0000 |
| Subject: | Re: [Coding Standards] Loading all files at once | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-47425@lists.php.net to get a copy of this message | ||
On 7/11/07, Joshua Eichorn <josh@bluga.net> wrote:
-josh Alan Knowles wrote: So these statistics are saying a 15% improvement could be made by grepping all the ^require_once '......php';$ out of pear files, and putting them into a single file that calls require. This is an obviously simple task for either the installer or a optimization tool. But clearly is not sufficient to justify obfuscating the code in PEAR? For anyone requiring that degree of optimization, the minimal effort of pre-processing the libraries would probably be done after a significant amount of work doing various tasks like database caching, output caching, APC and many other methods and really is not a good justification for this change to the standards. <snip and paste...>
Some would say the having all the includes in a single file is the simpler to manage approach not the current way. I understand not wanting to change but I wouldn't call allfiles obfucationFrom what I'm reading, I'm seeing the following: * 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)
* premature optimization
* coding for tools (phar, etc.), instead of adapting or creating
tools (installers, converters, etc.) to perform the optimization
tasks from existing sources
* many projects use the existing standards, and PEAR stands to lose
its position of leadership if they disagree with the new standardOn a final note, it feels to me like the principal authors of the draft specifications in question are not listening to the community, but rather pushing their own personal agenda. Please let this be a community process. A number of individuals have proposed that the generation of allfiles.php and/or removal of require/include_once calls be done by the installer, and I think this idea is excellent -- particularly if there are options *not* to do these actions. This would serve the purposes of all three target audiences (as defined by Lukas), and not require a change to the actual CS. Additionally, the idea of a PEAR2_Loader class that can initialize/manipulate the include_path, load classes, and register with spl_autoload seems like a no-brainer. I respectfully ask that the draft be revised to incorporate these ideas. -- Matthew Weier O'Phinney mweierophinney@gmail.com http://weierophinney.net/matthew/