On 22 June 2011 15:27, Craig Ringer <craig@postnewspapers.com.au> wrote:
> On 22/06/11 07:59, Oliver Jowett wrote:
>> On 22 June 2011 01:08, Andreas Schmitz <schmitz@occamlabs.de> wrote:
>>> Hi,
>>>
>>> I've noticed that fetching a bytea field produces a lot of overhead when
>>> converting into a byte[] or InputStream. Looking at the code, I've
>>> produced a small patch (a lookup table for the hex codes) which makes
>>> the conversion faster. What do you think?
>>
>> Surprising.
>
> It's not at _all_ surprising that an array index lookup is much faster
> than two function calls and a bunch of branches. It'll probably JIT
> better and be easier on cache, too.
>
> If Oliver is lobbing around mostly bytea data and/or using big bytea
> fields I'm not surprised he's seeing this as at least somewhat of a
> hotspot. I've seen comments on bytea performance with JDBC here before,
> though nobody seems to have dug into it enough to track things down before.
(The patch was Andreas' work, not mine)
I'm interested in the benchmark results because
a) I would have thought that a smaller 1D array plus bitshift/or would
be about as fast as a 2D array and probably cache-friendlier.
b) the JIT should be inlining the function calls in the original
version anyway, and I'm surprised that the branches are that expensive
I've seen enough weird performance behavior from the JIT in the past
to be inherently suspicious of anything that claims to be a speedup
without numbers to back it up.
If we have a benchmark to work from, then I'm sure there's even more
performance we can squeeze out of it.
Oliver