Re: minute performance gain

Greg Beaver wrote:

I took the register_shutdown_function and moved it to the PEAR class constructor, inside the code that checks for destructors, and found a miniscule performance gain. Zend IDE's profiler reported that the time it takes to run 'PEAR.php'; decreased from .35 ms to .28 ms. By far the most significant performance hit comes from the require_once call, which leads me to believe that even using PEAR_Exception would do nothing to improve performance unless you put everything in 1 big-ass file. :) For comparison, I took the file <?php ?> and profiled it, getting .02 ms, so the time it takes to parse PEAR.php is about .26 ms - not exactly big potatoes.

Especially since everybody that cares can install one of the freely available bytecode caches. If I find the time I will benchmark MDB2 with and without lazy loading of PEAR after this improvement. However I have a hunch that not lazy loading PEAR is the way to go: - easily extend PEAR_Error (ok this could be solved by moving PEAR_Error into a separate file, which then would increase file I/O if you in the end do have to load PEAR.php) - not have to mess with writing a custom expectError() - not have to mess with writing my own destruct emulation - dont have to mess with lazy loading the class when needed All in all with the latest improvements in the destructor I think we should get back to not lazy loading PEAR.php. 1) Subclassing PEAR_Error is good in order to know what type of Error object you are dealing with (and therefore what set of constants where used for the error code). 2) Having expectError() is one of the cool things about the PEAR_Error and unless you are using ErrorStack you loose out if you dont extend from PEAR. 3) The more PEAR packages the less you suffer from the require_once 'PEAR.php' 4) Get destruct emulation if you need it (with the recent updates you do in fact only get this emulation if you really need it .. this was one of the things we fixed and which is one of the reasons we should reevaluate if extending from PEAR is good or bad) regards, Lukas