Re: DB_Result fetchRow() && fetchInto()

# cox@idecnet.com / 2003-06-11 21:37:58 +0200: > From: "Roman Neuhauser" <neuhauser@bellavista.cz> > > # cox@idecnet.com / 2003-06-11 11:14:24 +0200: > > > From: "Roman Neuhauser" <neuhauser@bellavista.cz> > > > > these two methods are quite long, and have basically identical bodies. > > > > why doesn't one just call the other? > > > > > > Performance. > > > > Have you volunteered to keep the redundant code in sync? If you did, > > you failed. The answer should've been: bugs and more maintenance > > work. Diff their bodies: > > The code was synced. Just a minor issue (a result not free'ed) when: > 1) You use autofree > 2) Call limitQuery() > 3) Retrieve with fetchInto() > 4) The backend doesn't implement emulated row limit support It's still a bug that wouldn't have crept in if it weren't for code duplication. BTW, with the duplicity, pulling out 10,000 records out of MySQL takes avg. 0.335s, with fetchRow() calling fetchInto() it's 0.395s. (php(1) run in time(1)). The difference would be even smaller if fetchInto() called fetchRow() as we would save the minor overhead of passing the row array byref. > > With DB_FETCHMODE_OBJECT, one does $ret =& new $class, the other > > $ret = new $class => different behavior. > > Of course you haven't tested that. You'll get a marvellouse NULL instead of > the object if you change it. > I don't know if that's the expected behaviour in php, but in that case the > change would break DB_FETCHMODE_OBJECT. I wouldn't have thought this would behave this way, and you're right, I didn't test this exact version of the patch. I didn't say I did, either. > > Performance is nothing when compared to hard to maintain software, > > Performance is one of the problems of PEAR DB and should be fixed. I hold the argument that bad code organization is worse than a slight performance decrease. -- If you cc me or remove the list(s) completely I'll most likely ignore your message. see http://www.eyrie.org./~eagle/faqs/questions.html