RE: JDBC driver GREATLY speeded up by trivial fix - Mailing list pgsql-interfaces

From Peter Mount
Subject RE: JDBC driver GREATLY speeded up by trivial fix
Date
Msg-id 1B3D5E532D18D311861A00600865478CF1B184@exchange1.nt.maidstone.gov.uk
Whole thread Raw
In response to JDBC driver GREATLY speeded up by trivial fix  (William Chesters <williamc@paneris.org>)
Responses RE: JDBC driver GREATLY speeded up by trivial fix
List pgsql-interfaces
The getTimestamp() problem has been discussed a lot on this list recently.
I'm currently having horrible problems with my home system (hasn't recovered
well after the move) so I've not been able to sit down and apply the fixes.

As for receiveString(), it predates the driver merger (some 2 years ago?) so
as it's never broke it's been left. I suspect there's a lot of little
performace gems in there if we had time to sit down and do them.

Peter

--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council


-----Original Message-----
From: William Chesters [mailto:williamc@paneris.org]
Sent: Sunday, July 30, 2000 5:21 PM
To: pgsql-interfaces@postgresql.org
Cc: melati_development@messageboards.paneris.org
Subject: [INTERFACES] JDBC driver GREATLY speeded up by trivial fix

  First, sorry if this has been discussed before---I'm working with
the JDBC driver from the Postgresql 7.0 distribution.
  I recently had occasion to run a profiler over an app, and
discovered that it was spending a lot of its time at the following
line in org.postgresql.PG_Stream.ReceiveString:
       byte[] rst = new byte[maxsiz];

The point is that maxsiz is typically 8192, while the number of bytes
actually read into the buffer is the length of a field name
(i.e. never more than about 20).  The resulting performance hit is
absolutely horrendous---the fact that the poor JVM has to
zero-initialise the array is bad enough, but think of the effect on
the CPU cache and the garbage collector!
  My replacement for this routine is given below.  It's not obviously
the fastest possible implementation, but the effect on the performance
of database-intensive applications is just _unreal_: I mean integer
factors, rather than a few percent.
  I don't want to diss the efforts of the drivers' authors, but I
couldn't help noticing a few other horrors lurking around, like in
ResultSet.getDate and .getTimestamp both doing new SimpleDateFormat
every time they are called, which is pretty expensive if you look at
Sun's sources.  [Incidentally .getTimestamp is broken by the 7.0
backend ...]  Is it being actively maintained?  Can I help?

Best wishes,
William



 private static final class FinalByteArrayOutputStream     extends ByteArrayOutputStream {   public
FinalByteArrayOutputStream(intsize) {     super(size);   } }  /**  * Receives a null-terminated string from the
backend. Maximum of  * maxsiz bytes - if we don't see a null, then we assume something  * has gone wrong.  *  * @param
maxsizmaximum length of string  * @return string from back end  * @exception SQLException if an I/O error occurs  */
 
 public String ReceiveString(int maxsiz) throws SQLException {   FinalByteArrayOutputStream buf = new
FinalByteArrayOutputStream(20);
   try {     for (;;) {       if (buf.size() >= maxsiz)         throw new PSQLException("postgresql.stream.toomuch");
       int c = pg_input.read();       if (c < 0)         throw new PSQLException("postgresql.stream.eof");       else
if(c == 0)         break;       else         buf.write(c);     }   }   catch (IOException e) {     throw new
PSQLException("postgresql.stream.ioerror",e);  }
 
   return buf.toString(0); }


pgsql-interfaces by date:

Previous
From: Peter Mount
Date:
Subject: RE: JDBC problem with DELETE
Next
From: William Chesters
Date:
Subject: RE: JDBC driver GREATLY speeded up by trivial fix