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

Pádraic Brady wrote:

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? PEAR2 is targetting 5.2+, and depending on how things work out 5.2.x could easily become the minimum version.

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. You can also easily use a phing script to generate customized include files for you packages and in PEAR2 approach you don't have to munge every file. Hopefully PEAR2 would be to have some tools, at least for generating custom include files for packages like MDB2 with driver subpackages.

The goals of the require_once changes are (there may be other things too, this is just what I remember as the big items): make the use of __autoload possible be opcache friendly make it possible to use PEAR without messing with your include_path make it easy and consistent for new developers to get started using a pear package (just include the packages allfiles.php and your good to go) and not really a goal but a benefit is it makes it much easier to serialize a PEAR class since its easy to get all the classes you need include before things are unserialized. So if someone has a suggestion for something else that meets these goals were willing to listen but the current pear approach doesn't meet any of them so sticking with how things currently work isn't much of an option. -josh