Teofilis,
I have spent some time looking at your patch and trying it on different
JVMs. I was amazed how poorly the sun JVM handles this case. In fact I
saw performance differences of as much as 40X between the your code and
the sun code. (I think that was on a 1.2 jvm).
So I am inclined to include this patch. The reason I haven't yet, is
that I am investigating setting the 'client_encoding' parameter on the
server which would cause the server to encode everything to/from UTF8 so
that the client could always use this faster code. This would only be
possible if using a 7.3 server. Earlier releases didn't always have
support for this built in since it was a compile time parameter. But my
understanding is that in 7.3 the server always has this capability and
it is no longer a compile time option.
thanks,
--Barry
Teofilis Martisius wrote:
> Hi,
>
> While testing PostgreSQL JDBC I have noticed that it uses byte[]->String
> conversion everywhere via 'new String(byte[], encoding)' constructor. I
> found the implementation of that constructor painfully slow at least in
> Sun's JDK 1.3.1 and 1.4.0, a bit better in gcj 3.2. I have made a patch
> that uses my own UTF-8 Unicode byte[]->String constructor and it speeds
> up iterating a resultset ~1.5-2x on Sun's JDK.
>
> Please confirm if anyone has similar experience. I will post the patch
> to this mailing list if you are interested in it. Too bad it only works
> with Unicode databases, and uses the default String constructor for other
> character codings.
>
> Teofilis Martisius,
> teo@teohome.lzua.lt
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>