Re: Re: cvs: pear /Validate/Validate US.php

On Thu, 2002-06-20 at 05:26, Brent Cook wrote: > On Thu, 20 Jun 2002, Alexander Merz wrote: > > > Tomas V.V.Cox wrote: > > > Please do not include the File dependency for the class for doing such > > > little work, makes no sense. Also take in mind that Validate methods are > > > really static functions and should be used in the same way normal PHP > > > functions works (return bool and trigger an error on internal error). > > > Prepend the "@" operator if you don't want to show the error). IMHO > > > this > > > path should be reverted. > > > > No. > > a) static or not, the PEAR user expect a PEAR_Error in case of failure, > > if this behavoir isn't constant, we lost one of the importest PEAR features > > b) if the user uses PEAR, he know that he can not get the best > > performance - else he would use a customized function > > I converted a class of my own from using trigger_error and returning > boolean to using PEAR::raiseError. The result was interesting - it was > almost twice as slow in some cases. You can see the results here: > > > http://www.brentandtiffany.org/projects/dba/benchmarks/simple_raiseerror.pdf > > http://www.brentandtiffany.org/projects/dba/benchmarks/simple_trigger_error.pdf > > The driver for these tests looked like this for the simple > boolean-returning code: > > for ($i=0; $i<$transactions; ++$i) { > $testKey = rand (0, $maxTestKey); > $testData = $testDataArray[rand(0, $maxDataIndex)]; > switch (rand(0, 3)) { > case 0: > $result = @$testDB->insert($testKey, $testData); > break; > case 1: > $result = @$testDB->delete($testKey); > break; > case 2: > $result = @$testDB->replace($testKey, $testData); > break; > case 3: > $result = @$testDB->fetch($testKey); > } > if ($result) { > ++$actualTransactions; > } > } > > with the only difference for the raiseError-returning code being the last > three lines: > > if (!PEAR::isError($result) { > ++$actualTransactions > } > > The frequency of errors being returned from the method calls was about > 50%, since the keys were picked at random and didn't necessarily exist in > the database at any given time. With 4000 attempted transactions, using > raiseError (which occurred about 2000 times) resulted in doubling the > execution time for the transactions as a whole. > > In a real-world application, this might actually amount to less time > (hopefully fewer errors) than would be noticed, but the overhead of using > raiseError is certainly nontrivial. > > > e) Using raiseError will make your life easier, if you start to migrate > > the PEAR stuff to PHP 5 and using the try-catch-mechanism. > > Note: It really wasn't a big deal to convert from one to another, since I > just used the simple $message portion of raiseError and ignored the other > options. YMMV. Hi Brent, IMHO speed is not an important issue here, if it is you are abusing PEAR errors. They are an emulation of exceptions, and should be used for just that - failures that count as exceptions. This means these errors should be rare, which means performance is not a big issue. PHP's error handling sucks, hard, that's why PEAR_Error exists. And it has been designed to be forward-compatible with PHP 5. Starting to mix the two is _not_ a good idea. Converting to try/catch may work, but why do that when you can keep using raiseError and be PHP 4 BC? - Stig