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

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. - Brent