Sure, I'll monitor this, dont happen too often. Thanks. Regards, Saša Stamenković
On Thu, May 27, 2010 at 8:27 PM, Thomas D. <[email protected]> wrote: > Hi, > > Bill Karwin wrote: > > I wrote the following on the February thread with Ulf Wendel that you > > linked to, but I think it bears repeating: > > > > [...] > > > > Peter seems to say that the "overhead" of using prepared statements is > > that they are 14.5% *faster* than using a non-prepared query > > execution, at least in this simple test. I'd expect the relative > > difference probably diminishes with a more complex query or a larger > > result set. > > Peter was testing *real* prepared statements. > Real prepared statements are prepared on the DBE server-side. > > Most people think, that when they are using PDO, which force them to use > prepared statements in most cases, that they are using *real* prepared > statements, but they aren't! PDO is just another abstraction PDO just > emulate prepared statements. That means, preparation is done client-side. > It's more a validation than preparation. > This has *nothing* to do with server-side prepared statements. Most of the > benefits a DBE is offering you when it is supporting prepared statements > cannot be used by client-side prepared statements. > > That's why client-side prepared statements from a high performance > viewpoint are real show stopper. They do nothing than wasting time ;-) > > For more: > <http://blog.ulf-wendel.de/?p=187#pdo> > > > > In any case, we should be careful about citing round-trips as a > > significant performance factor, because it discourages people from > > using prepared queries when they should. > > *FULL ACK* > > If anyone is not using some kind of abstraction like Zend_Db*, everyone > should prefer PDO. Not because it is faster (it isn't, but it isn't really > slower!), but because it is more secure by design, when you work with > prepared statements (because it is enforcing some kind of security). > > But you should understand it. You should know why you are using PDO and why > you should prefer it. You shouldn't use something, just because someone has > told you "It's better" ;-) > > > -- > Regards, > Thomas > >
