Uh, your SQL query is 100,000 characters long? If I change your benchmark to use "select foo from bar where baz = ?", prepare_cached is 333% faster. I'm thinking my test is a bit more realistic. | [reply] |
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.
| [reply]
[d/l] |
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] |