Clear questions and runnable code
get the best and fastest answer
New twist for DBD::mysqlby gmax (Abbot)
|on Sep 14, 2004 at 10:06 UTC||Need Help??|
A new DBD::mysql
Patrick Galbraith, senior developer at MySQL AB, has made available a modified version of DBD::mysql. It is not in the CPAN yet, (and I believe it will go there when the maintainer is satisfied with the tests) but it is usable.
What is the fuss about? This version makes a few interesting additions to this popular module:
Some documentation is available at this OSCON presentation (PDF).
As I mentioned before, it is not on CPAN yet. You must get it from the author's CVS and fiddle a little bit to get it up and running.
The main problem is that this new version requires the client library that comes with MySQL 4.1, and if you are already using MySQL 3.23/4.0 in your box, you should install the 4.1 version, and since it is not advisable to trust new software before testing it, you shold install it without removing the working server. This is not very difficult, but not easy for the average Joe either. Therefore, some caution should be necessary. Moreover, you may need to compile the server source rather than using the binaries if your system is using old libraries (at least for the embedded server this is what I had to do).
This change is not easy to measure up, because the benefits of a prepared statement may vary significantly depending on the query complexity. Nonetheless, I made some measurements, and even with a simple query, the difference is visible. (Please refer to Speeding up the DBI for a detailed explanation of the profiling methods used here)
The benchmarking code will simply prepare two qwueries, one without using the new feature and one taking advantage of it.
Benchmark: timing 5000 iterations of emulated, prepared... emulated: 24 wallclock secs ( 6.88 usr + 2.52 sys = 9.40 CPU) prepared: 20 wallclock secs ( 6.84 usr + 2.31 sys = 9.25 CPU)
The result shows that there is a (little) convenience with the true prepared statements. The real difference, though, comes when we analyze the profiling output.
emulated DBI::Profile: 22.655414s (150003 calls) benchdbd.pl @ 2004-09-14 10:31:07 'FETCH' => 0.000006s 'STORE' => 0.000237s 'execute' => 20.919974s / 75000 = 0.000279s avg 'fetchall_arrayref' => 1.735029s / 75000 = 0.000023s avg 'prepare' => 0.000168s prepared DBI::Profile: 19.629611s (150003 calls) benchdbd.pl @ 2004-09-14 10:31:07 'FETCH' => 0.000007s 'STORE' => 0.000103s 'execute' => 17.339136s / 75000 = 0.000231s avg 'fetchall_arrayref' => 2.289909s / 75000 = 0.000031s avg 'prepare' => 0.000456s
Notice first that the 'prepare' method takes longer when using the real prepared statements. This is because the emulated 'prepare' is just a way of passing parameters, and it does not call the dataabse server at all. The difference is all in the 'execute' method, where the emulated version takes 15% longer than the new implementation.
Update Sep 14, 2004 at 11:23 GMT+1
_ _ _ _ (_|| | |(_|>< _|