When you refer to bound parameters, do you refer only to the use of
$sth->bind_param, or would calling $sth->execute($foo,$bar) also qualify.
Is there any difference between using these methods other than clarity of
code?
Thanks
Clint
> -----Original Message-----
> From: Jeffrey W. Baker [mailto:[EMAIL PROTECTED]]
> Sent: 15 October 1999 03:50
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: More on web application performance with DBI
>
>
> "Jeffrey W. Baker" wrote:
> >
> > Perrin Harkins wrote:
> > >
> > > On Thu, 14 Oct 1999, Jeffrey Baker wrote:
> > > > Zero optimization: 41.67 requests/second
> > > > Stage 1 (persistent connections): 140.17 requests/second
> > > > Stage 2 (bound parameters): 139.20 requests/second
> > > > Stage 3 (persistent statement handles): 251.13 requests/second
> > >
> > > I know you said you don't like it because it has extra
> overhead, but would
> > > you mind trying stage 3 with prepare_cached rather than
> your custom
> > > solution with globals? For some applications with lots
> of SQL statements,
> > > the prepare_cached appraoch is just much more manageable.
> >
> > Okay. I'll try it out tomorrow and post the results. However, my
> > application uses this approach and I'd say it's in the 99th
> percentile
> > with respect to number of different statements =:-)
>
> I just performed this benchmark. The Stage 3 optimization using
> prepare_cached gets 152.72 requests/sec. The end result is this:
>
> Zero optimization: 41.67 requests/second
> Stage 1 (persistent connections): 140.17 requests/second
> Stage 2 (bound parameters): 139.20 requests/second
> Stage 3 (prepare_cached): 152.72 requests/second
> Stage 3 (global references): 251.13 requests/second
>
> You can see that prepare_cached isn't much of an improvement over
> prepare. I've profiled this stuff in the past, and the prepare method
> really is quite expensive. A nice project for someone with sufficient
> spare time would be to optimize that code path.
>
> -jwb
>
