Oliver Jowett wrote:
> I haven't seen the string manipulation to be much of a problem with
> the current driver in the profiling I've done (it'll be quite
> application specific though). And I'd have thought the stringbuffer
> monitors would be essentially uncontended and cheap to enter. What are
> the hotspots you see?
>
See below...
> Also I am fairly suspicious about claims that native byte order will
> make things go measurably faster. Do you have any profiling or
> benchmarks to back that up? The low-level manipulation of protocol
> data barely shows up on the profiles I've done.
I haven't made any benchmarks and I admit that as long as the client and
server runs in separate processes, the gain will be relatively small.
Context switching and socket management are the real time consumers.
I'm the author of PL/Java. It uses its own JDBC driver on top of SPI.
The main reason for thas is that I don't want the overhead of streaming
data and flipping byte order when everything is readily available in
memory. When "client" and "server" resides in the same process the
overhead is measurable. By using java.nio in your JDBC, I beleive it
would be possible to not just use native byte ordering, but perhaps also
to create a nice abstraction allowing direct access to structures in
memory rather than streaming data, thus obliviate the need for my own
driver. And PL/Java will never run on Java 1.3 or older :-)
Do you have any opinion on that?
Regards,
Thomas Hallgren
