Chris Smith wrote:
>>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.
Not having benchmarked either approach I can hardly disagree :) Object
creation is a real bugbear in our app so I tend to reflexively avoid it
where I can, even when the direct CPU benefit is dubious.
>>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).
I can only speculate, since the java profiling tools are so bad -- I'm
yet to get a good CPU profile out of this bit of code. It all *seems*
fairly cheap so I can only guess that it's an accumulation of many small
operations along the way. Object creation doesn't seem to be the root of
the problem, as even with heap settings that avoid GCing frequently it's
chewing CPU the whole time, not just during GCs.
I should really do some more profiling of this area, I've just been
avoiding it because it's so painful to do..
-O
