Oliver Jowett wrote:
> When I put that code in I was trying to keep the cost of queries that
> didn't need to be transformed (due to non-query reasons e.g. state of
> autocommit) to a minimum -- the current approach is certainly cheaper
> and probably generates less garbage than the more obvious approach,
> but I don't know by how much. At the time it was a fairly big change
> and I was trying to preempt objections :)
Okay. As far as I can see, the calculation of all of these things requires
the following:
1. Two comparisons per query character.
2. A constant 7 assignments.
3. A constant 28 comparisons.
4. Once extremely short-lived String object, that shares it data via
substring).
Frankly, that should be negligible cost on anything faster than a 6052
processor.
> Also please don't reparse on each execution (which is the other thing
> that isSingleSelect and friends try to avoid)
Definitely. I don't plan to repeat the calculation; only to avoid deferring
it. I think the deferred calculations introduce unnecessary work on every
execution, just to avoid about 100 processor cycles or so when first parsing
the query.
> This currently chews a *lot* of
> CPU on the Java side while executing -- on the order of a 50/50 split
> between Java and the backend.
I'm interested in your ideas on why this is the case. I suspect a lot of it
may have something to do with building the text form of the parameters to
inject them into the query (in which case I'm working on solving exactly that
problem by making these changes).
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
