Re: Error_Raise API change, major 2x speedup question

I thought the general plan was to leave PEAR_Error alone, and try and work out a replacement that uses throw/catch.. in PHP5.. - seems a good point to introduce a major overhall.. Is it really impossible to look up the calling class from debug_backtrace? you could then, just add $error->isErrorType('DB_DATAOBJECT_ERROR_ABCEDFG'); which can exploded on the ERROR, compare it with the class (debug_backtrace) - then compare the error no with the constant($errorstr) Or Did I miss the logic on adding this? Regards Alan Greg Beaver wrote:

Hi, After Alex Merz's thoughtful email regarding alphaworks, in which he happened to mention performance overhead with my Error_Raise class, I did some profiling work on Error_Raise. He was right - it was twice as slow to do a raising of an error as PEAR::raiseError(). :) I've done some work since then, and using xdebug's profiler, have found a way to keep the same API and only lose 25% of the speed compared to PEAR (0.0001980066 seconds versus 0.0001569986 seconds), or, change the API and have it be exactly the same speed (twice as fast as current API). Would the API change described below change anyone's potential -1 to a +1? I accomplished the speed increase by removing validation code and moving other functionality to seldom-used functions like getMessage() that won't affect most-often-used performance. Here's the difference in API: current API: Error_Raise::initialize('package', errormsgcallback); Package_Raise::error(PACKAGE_ERROR_CODE[, array('info' => $thing, 'anotherinfo' => $thing2)]); faster API: Error_Raise::initialize('package', errormsgcallback); Error_Raise::error('package', PACKAGE_ERROR_CODE[, array('info' => $thing, 'anotherinfo' => $thing2)]) Note that initialize is a call-once deal - with nearly 0 execution time in the faster API, as it only sets an array index. I think users can live with the faster API, and having to type in the package name. They could also define the class manually like so: class Package_Raise extends Error_Raise {

    function warning($code, $args)
    {
       return Error_Raise:('package', $code, $args);
    }

    function error($code, $args) ... etc.

} The impact of including a few extra files is negligible for all but the most extreme situations, and I suppose they would require custom code anyways. If any of you think I'm wrong and have the time to explain, I'd love to hear it - it will help me re-design to fit the requirements you feel are most important, while keeping what I feel is most important (the perfect balance, no?) Incidentally, one other possibility I would like is to have 2 versions of the error handler, the slower, safer one that validates all inputs and throws internal exceptions on malformed input (passing "function_exists" as a callback for generating error messages, for example), which can be used for extreme debugging, and this one, which can be used for production environments where the main things returned will be errors due to invalid user input, and other non-programmatical bugs. In other words, this could be used: if ($do_debug) {

    include_once 'Error/debugRaise.php';

} else {

    include_once 'Error/Raise.php';

} This would satisfy the need for safety and the need for speed without compromise. The API would be identical. Comments? Greg

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com