If you think that they might be slower, but don't know, then that tells me you haven't benchmarked it.
Exactly right -- neither have I peered into the DBI code, but I will do both before I make any sweeping changes. But I'm doing this because I want to find out what the best possible solution is, in terms of safety (not crashing, getting the right results without error) and also in terms of clarity (getting the code to be as clutter-free as possible).
Furthermore, you probably haven't profiled the code to see if it's even worth bothering to try to find a speed-up in that area.
That's an interesting one -- because part of the profiling will be on the client machine (where my code is located) and part if it will be on the server (where DB2 is). But I'll see what I can do; I've already talked with the DBA and I'm sure I can ask him to help out with this exercise.
Until you know that you have a speed problem to solve, and that the binds are the problem, you shouldn't consider removing them to make stuff faster. Only consider removing them to make the code easier to read.
I'm equally concerned about speed and readability, but if pressed would probably favour the latter. You can always buy more hardware, but you may not be able to afford another two weeks while a developer tries to understand some chunk of code with half a dozen authors. Or, worse, goes ahead with some change that turns out to be wrong because she/he couldn't understand the code.
Alex / talexb / Toronto
"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds
| [reply] [d/l] |