Re: updated docs for Error_Raise

Martin Jansen wrote:

On Wed Aug 20, 2003 at 06:1024PM -0400, Greg Beaver wrote:

There is one other concern that I hadn't realized was an assumption on my part - performance suffers slightly if we continue to use existing raiseError. My solution circumvents this problem through new methods that break BC, using existing raiseError would add a slight performance penalty.

Do you have any concrete numbers for that? Perhaps we can find a way to get back that performance decrease elsewhere in the code. Yes, it was about twice as slow, using xdebug's profiling, and also a test file that loaded a file 100 times (each file had a loop that called raiseError() 2000 times). I also moved the debug_backtrace() call out of the constructor for PEAR_Error, and into the error-raising method. This was because it's pretty much useless in the error - you can't automatically determine the source of the error using it. If it is only called in the method used to raise an error, then it is possible to parse it for line number/file information. debug_backtrace() is a very expensive function - putting only 2 calls in more than doubled the performance cost for deep function nesting. we're still talking about .02 versus .04 seconds for loading, but that seems to matter in some cases (none that I use, but Cache_Lite's docs certainly highlight it as a performance hit).

One of the most common complaints about PEAR's error handling is that the PEAR.php file adds a ton of overhead.

Maybe I'm just dumb at the moment, but why don't we move PEAR_Error to it's own file and require_once() it in PEAR.php? Or ar PEAR_Error and PEAR connected in a way that I have missed yet? No, you're not dumb, this is the best solution. The biggest problem, actually, is not just the file size, but the fact that PEAR_Error extends PEAR. The destructor registration slows down things. I realier proposed the possibility of switching this so that PEAR extends PEAR_Error. If the error-raising methods are moved to PEAR_Error, there would be no BC implications.

Greg