All the Perl that's Practical to Extract and Report

DBI performance: true or false

jdavidb on 2006-08-08T18:33:01

I'm being told by a Java programmer that use of the bind_param method on a statement handler is more efficient than calling execute with the parameters. He thinks that if I don't use bind_param that Perl does the binding instead of allowing Oracle to do it and so Oracle has to parse two different statements that don't match if I execute it twice. True? False?

Update: And the answer is: false. He checked in the database. He sounded mildly surprised.

Sort of right for the wrong reasons

runrig on 2006-08-08T19:01:55

execute() calls bind_param for each argument. Which means it'll bind parameters every time you call execute() if you do it that way. If you instead are able to call bind_param() just once to bind the SQL placeholders to variables, and execute() with no arguments (then change the value of the variables, call execute() again, etc.), you save those extra implicit calls to bind_param(), which makes it slightly more efficient to do it this way...slightly...I think (...someone please prove me wrong). But his reasons were bogus.

Nevermind

runrig on 2006-08-08T19:05:54

I'm wrong:

The "bind_param" method takes a copy of $bind_value and associates...

You're binding a copy of the value, not the variable itself (like with bind_columns). I'm way off.

Re:Nevermind

Matts on 2006-08-08T21:35:13

Yeah, plus internally the DBD implementations do all this work in C, they don't tend to have much access to the perl level.

It's also worth noting that this is entirely DBD driver dependent. I believe old versions of the MySQL DBD used to bind the variables into the string sent to the database because MySQL had no bind param support (it does now, IIRC).