Re^5: mod_perl was hosed by a bind variable

Not to be a pedant, but prepare() can be faster than prepare_cached() 56% faster, in fact ;)

To be a pedant, your benchmark is highly misleading. prepare() might be faster, but the speed gain is barely visible when you actually execute the query. When you're using a database that supports prepared queries (e.g., Oracle), the cached form is a win. In the example you show, no communication with the server happens, since current versions of MySQL don't support prepared queries. What you're seeing is bookkeeping overhead.

Comment on Re^5: mod_perl was hosed by a bind variable Download Code

Replies are listed 'Best First'.
Re: Re^5: mod_perl was hosed by a bind variable by tantarbobus (Hermit) on Feb 02, 2004 at 00:56 UTC
I don't think my benchmark is misleading. I set out to show that in at least one case prepare() CAN be faster than prepare_cached(), to provide a counter example, as it were. The benchmark that I posted shows that in some cases prepare() CAN be faster than prepare_cached() nothing more, nothing less. Now, prepare_cached()is normally faster and I am not saying that it is not, but there a point where the overhead of calculating the hash and doing the hash lookup takes more CPU time than it does for DBD::mysql to walk the string looking for placeholders.	[reply]

Replies are listed 'Best First'.

Re: Re^5: mod_perl was hosed by a bind variable
by tantarbobus (Hermit) on Feb 02, 2004 at 00:56 UTC

I don't think my benchmark is misleading. I set out to show that in at least one case prepare() CAN be faster than prepare_cached(), to provide a counter example, as it were. The benchmark that I posted shows that in some cases prepare() CAN be faster than prepare_cached() nothing more, nothing less.

Now, prepare_cached()is normally faster and I am not saying that it is not, but there a point where the overhead of calculating the hash and doing the hash lookup takes more CPU time than it does for DBD::mysql to walk the string looking for placeholders.

[reply]