Re: tuning/profiling

On 19-Oct-05, at 5:18 PM, Kevin Grittner wrote:

> Ken,
>
> If you're going to be running tests and benchmarks anyway, you
> might want to consider replacing the synchronized collections
> (Vector and Hashtable) with their unsynchronized counterparts
> (ArrayList and HashMap). While each synchronized block only
> costs about one microsecond (in benchmarks I've run), there is
> a potential hidden cost to them -- they may prevent some of the
> more aggressive optimizations available to the JIT.
Vector and Hashtable are remnants from jdk1.1 and we should probably
look
at replacing them, however see my comment below about thread safety.
>
> In case you haven't run into this issue, each thread can keep a
> cached copy of any variable it uses. It does not need to re-read
> the variable from shared memory except when it references the
> variable after the thread has entered any synchronized block
> after the last read. It does not need to write any modifications
> to shared memory until it leaves a synchronized block. The
> profiler could show this access to shared memory as a cost
> far from where the synchronized block itself, and it could affect
> variables that have nothing to do with the collections.
> Synchronizing on any object affects all cached variables.
>
> This is not hypothetical; I have seen these JIT optimizations in
> production environments.
>
> As far as I'm aware, the driver is not thread-safe anyway (and
> is not required to be so by the JDBC spec) except for the
> Statement.cancel() method. One would have to pay special
> attention to that.

Huh ? any web application would be sharing connections, and the
driver itself
>
> Having said all that, you're more likely to get big gains by
> addressing whatever the profiler highlighted.
>
> -Kevin
>
>
>
>>>> Ken Geis <kgeis(at)speakeasy(dot)net> >>>
>>>>
> Hi. I just did some investigation into improving the performance of
> the JDBC driver. I want the best performance for my application,
> and I
> would love to be able to make PostgreSQL more competitive.
>
> I wrote a simple benchmark that would be doing an action common in my
> application (fetch ~11000 rows from a table with a date, four
> numeric(9,4) columns, and an integer.) I ran this through a profiler
> and found some hot spots. In the end, I was able to squeeze out at
> least 50% improvement with a small amount of changes to driver code.
>
> Before I submit patches, I must run my changes against the test suite
> and other benchmarks. Then I will break my patches into independent
> pieces. Some of my changes may be controversial because they may be
> less robust than current, but I am making some assumptions about the
> server protocol (like that date strings will never contain Unicode
> digits.)
>
> Does anyone have a benchmark they'd like me to run? I could run
> ECPerf, PolePosition, TPC-W, or Jdbcbench.
>
>
> Ken
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>