Re: Performance problem with timestamps in result sets

Thomas Dudziak wrote:
> On 3/8/06, Michael Paesold <mpaesold(at)gmx(dot)at> wrote:
>
>
>>This should be 1 ms per getTimestamp call, shouldn't it? The time is the
>>aggregate time for ~8000 calls. That is still rather slow, yeah, but it is
>>so with profiling.
>
>
> Yep, but as I said, the others are much faster. E.g. getString takes
> 140ms for 5460 calls, and getInt 570ms for 10920 calls, so its
> probably not so much the profiler.

getTimestamp() does many more internal method invocations than getInt()
so the per-method overhead of your profiler will have a larger effect on
getTimestamp(). Consider that some of the utility methods that
getTimestamp() calls internally are very small and will be inlined by
the JIT in normal operation..

I would try an external benchmark without profiling to get more
comparable numbers: record start time, call getTimestamp() 1000000
times, record end time; repeat for getInt(). A warmup loop is a good
idea too if you want to measure the JITted performance, 8000 invocations
is not much in terms of what the JIT does.

> Also, I was merely asking whether there is something that could be
> done to bring getTimestamp at least in the same region.

There is no simple go-faster change I know of. Then again I've not heard
of any performance problems in this area before.

If you do come up with some performance-improving changes, by all means
post them to the list for integration into the official driver..

-O