Re: on the coding standards - Re: [PEAR-DEV] PEAR Group June 24 2007 Meeting Minutes

Hi, >The point of these changes is to put the performance control back in >the hands of end users and I for one can't wait. I'm head developer >(okay only developer *shakes fist at boss*) on quite a large PHP based >product, about 25% of our page generation time is wasted in >include_once calls in PEAR packages we use. 5% of the generation time >is include_once 'PEAR.php'. Don't get it. A require_once and require are little different to an opcode cache. Both require a file, both lead to an opcode cache caching that file to memory (hopefully the function/class bits too unless conditionally required or autoloaded. The main speed different comes in since require_once needs to figure out the full path to the referenced file to check it against the list of previous require calls. This speed hit was reduced in PHP5.2 when they added a realpath() cache - you can reduce it further by skipping the need for any realpath() call in the first place by using the full paths as much as possible (or use a build tool to insert realpaths for a platform). One assumes PEAR2 is targeting the PHP 5.2 platform primarily? >Having the option manually listing which parts of the PEAR packages to >include, with no extra overhead from a class_exists() check, would be >a god-send. As would having alltests.php when first using a package, >drop that in get it all, once its all working profile and find out >exactly what using and list only that. This is why build tools exist. Phing + PCRE is God ;). You can commit any conceivable attrocity against require_once/require as many times as you wish with the right build script. I've used it before for building opcode and non-opcode versions of applications depending on the target platform and which would be more optimal. Paddy Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ----- Original Message ---- From: Adam Ashley <aashley@adamashley.name> To: pear-dev@lists.php..net Sent: Monday, July 9, 2007 11:36:00 AM Subject: Re: [PEAR-DEV] on the coding standards - Re: [PEAR-DEV] PEAR Group June 24 2007 Meeting Minutes ----- Message from alan@akbkhome.com --------- > Arnaud Limbourg wrote: >>> Package 2.0 from what I remember still has some flaws which make >>> it inferior from a usability point of view to version 1.0. (I >>> haven't converted any packages to it yet as it was just to much >>> hastle and no clear benefits last time I looked.. over 9 month ago >>> mind you..) >> >> Do you remember what flaws ? > All a can remember is that the history of changelog was moved around in > such a way that just copy and pasting the old release details into the > changelog area was not feasible.. It's been a long while since I looked > at it thought.. Well thats not true, that's how I've been doing my updating of Auth and Config's package 2.0 files since september last year. works fine. c&p and add the <release> tag around it. >>> allfiles.php - looks like a kludge - It not something that looks >>> like a consideration for a standard requirement, although if >>> package owners want to add it they can.. >> >> Why is it a kludge ? Many people who need performance can load up >> all the needed files at once. > If someone really needs to optimize to this level, then configuring the > opcode compiler with a list of files based on logging of > get_included_files would prove far more efficient here. This kind of > solution is unlikely to save that much performance wise, and just get > in the way of developers and deployment. >> >>> "*_once including of files not allowed" - Requires autoload() >>> mechanisms, which are not considered by all to be the best >>> mechanism for loading files and documenting code.. - This is a >>> significant change and would need serious backing by all members.. >>> I think a long time ago someone proposed >>> class_exists(.....) ? false : require_once '......'; This seems a >>> better compromise - as it solves 2 problem with one shot. - >>> although an import statement would be better...... >> >> The issue trying to be solved here is to be opcoce cache friendly. > the" class_exists ? require_once " should do that AFAIR, saying that, > the prebuilding of included files and proper analysis is really the > best solution though. To answer both of these, using require is an order of magnitude faster than require_once (http://talks.php.net/show/lca07/11). also class_exists ? require_once is just as bad performance wise, a miss is just as slow and a hit adds unneeded overhead. The point of these changes is to put the performance control back in the hands of end users and I for one can't wait. I'm head developer (okay only developer *shakes fist at boss*) on quite a large PHP based product, about 25% of our page generation time is wasted in include_once calls in PEAR packages we use. 5% of the generation time is include_once 'PEAR.php'. Having the option manually listing which parts of the PEAR packages to include, with no extra overhead from a class_exists() check, would be a god-send. As would having alltests.php when first using a package, drop that in get it all, once its all working profile and find out exactly what using and list only that. Adam Ashley ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/