From: | Tim Kientzle <kientzle(at)acm(dot)org> |
---|---|
To: | Gunnar R|nning <gunnar(at)candleweb(dot)no> |
Cc: | PostgreSQL general mailing list <pgsql-general(at)postgresql(dot)org>, "Keith L(dot) Musser" <kmusser(at)idisys(dot)com> |
Subject: | Re: Re: JDBC Performance |
Date: | 2000-09-29 01:06:48 |
Message-ID: | 39D3EB28.E39675A4@acm.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Gunnar R|nning wrote:
> I think we can improve the performance of the JDBC driver alot still.
> ... The remaining largest bottleneck in my JDBC codebase now is related to
> byte/char conversions in the Sun JDK implementation. My profiler tells me
> that Sun JDK 1.2.2 for some reasons create new instances of the converter
> class every time you do an conversion...
A custom converter may not really help; I experimented with that for
another project and it really didn't make that big of a difference.
You might get some advantage by manually handling the converter object,
keeping a reference to it in the database handle so you don't have to
re-instantiate that class every time. That might help.
You might be able to optimize out some char-to-byte conversions.
For example, if someone "prepares" a SQL statement, you can pre-convert
the entire statement (less placeholders) into bytes, then
convert only the individual arguments; this would speed up
repeated uses of prepared statements. (I.e., break the original
statement
at ? placeholders, convert each block of static text into bytes,
store the statement as a list of byte[]. When someone executes
a statement, convert just the arguments into bytes and emit the
complete statement.) I've had very good luck with this strategy
for building and caching mostly-static web pages within Java servlets.
- Tim
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2000-09-29 01:19:36 | Re: Checking number of entries |
Previous Message | Alejandro Federico Pérez López | 2000-09-29 01:01:22 | A newbie question |