Skip site navigation (1) Skip section navigation (2)

Re: Minor performance improvements

From: "Stephen Denne" <Stephen(dot)Denne(at)datamail(dot)co(dot)nz>
To: "Kris Jurka" <books(at)ejurka(dot)com>
Cc: <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Minor performance improvements
Date: 2007-02-27 03:08:44
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
I'm sad to say that I have not created any micro-benchmark tests, and unfortunately the improvements are very minor, and far overshadowed by the variability I get from my system.

My code wasn't even using Send(byte buf[], int off, int siz).

The portion of my application that I am testing is essentially doing bulk loading. I'm using PreparedStatement of insert SQL, a lot of setXXX() and addBatch() calls, and the occasional executeBatch().
Running in Java5, using jdbc driver 8.2.504.jdbc3 connecting to PostgreSQL 8.2.3 with about 40Gb data and indexes in it, all on WinXP.

The test ends up performing about 5200 inserts.

The improvement I do see (which prompted my email) is in fewer bytecodes being used to perform the same functionality.

Adding profiling in to such small methods also results in a larger impact (I'm using YourKit Java Profiler).

That said... this implementation was about 30% faster over about 88,000 calls:

    public void SendInteger4(int val) throws IOException
        pg_output.write(val >> 24);
        pg_output.write(val >> 16);
        pg_output.write(val >> 8);

SendInteger2 was similarly improved.

These changes meant that SendChar usage was reduced from about 560,000 calls to about 40,000, making it difficult to measure the time saved by removing the double up of the int to byte conversion.

Interesting thought about using _int4buf, and it took me a while to make up my mind whether it would be faster or not (using the "Java Puzzlers" technique of deciding what I think some code would do before testing my assertions). 

I think the difference in the overall work you are doing is that you are adding a buffer to buffer copy. Why write the values to _int4buf if you can write them into BufferedOutputStream's buffer? Most of the time you won't be going beyond the end of the buffer, so in general you'd be replacing three method calls with a call to System.arraycopy, which while extemely fast, I think would be slower than not calling it at all.

Stephen Denne.

-----Original Message-----
From: Kris Jurka [mailto:books(at)ejurka(dot)com] 
Sent: Tuesday, 27 February 2007 11:47 a.m.
To: Stephen Denne
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: [JDBC] Minor performance improvements

On Tue, 27 Feb 2007, Stephen Denne wrote:

> Four small optimizations in org.postgresql.core.PGStream:

Could you share some more of your results with us?  What sort of improvment did you see by making these changes?  Or could you share your test case code so we can do some timing of our own?

> 2) The byte masks are not required in SendInteger4 and SendInteger2, 
> as
> OutputStream.write(int) ignores the top 24 bits. Though if these are 
> removed I think comments should be included instead to clarify that 
> only the bottom eight bits get written.

Would using a class member byte[] _int4buf = new byte[4], filling it, and passing this to Send(byte buf[]) be better by avoid repeated method calls?

Kris Jurka

At the Datamail Group we value team commitment, respect, achievement, customer focus, and courage. This email with any attachments is confidential and may be subject to legal privilege.  If it is not intended for you please advise by reply immediately, destroy it and do not copy, disclose or use it in any way.

  This email has been scanned by the DMZGlobal Business Quality 
              Electronic Messaging Suite.
Please see for details.


pgsql-jdbc by date

Next:From: Kris JurkaDate: 2007-02-27 04:24:09
Subject: Re: Minor performance improvements
Previous:From: Oliver JowettDate: 2007-02-26 23:20:57
Subject: Re: parameterized queries and prepareThreshold

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group