db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[] constants instead of Strings where feasible
Date Mon, 29 Jun 2009 14:39:47 GMT

     [ https://issues.apache.org/jira/browse/DERBY-825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dag H. Wanvik updated DERBY-825:

    Derby Categories: [Performance]

> writeSQLCAGRP() should use byte[] constants instead of Strings where feasible
> -----------------------------------------------------------------------------
>                 Key: DERBY-825
>                 URL: https://issues.apache.org/jira/browse/DERBY-825
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Network Server
>    Affects Versions:
>            Reporter: Dyre Tjeldvoll
>            Assignee: Dyre Tjeldvoll
>            Priority: Minor
>             Fix For:
>         Attachments: derby-825.diff, derby-825.stat, derbynetclientmats_report.txt
> writeSQLCAGRP() writes Strings into the message being built. Profiling shows that it
is more expensive to write a String than a byte[] because the String must be converted to
UTF8. writeSQLCAGRP() writes 5 bytes for SQLState, and this is done by either writing a String
constant, or the return value from SQLException.getSQLState(). For the common case where there
is no exception (SQLState = 5xspace), or the exception is a "dummy" exception (SQLState=00000
or 02000, End of Data), this is wasteful because the String has to be converted to byte[]
each time, and in the case of the dummy exception, a new String object will be created each
time getSQLState() is called, even if the exception object is the same (there is no caching,
which is reasonable since exceptions are meant to be thrown, not kept around for a long time).
> A solution is to keep the commonly used SQLStates as byte[] constants that can be inserted
into the message with writeBytes().
> If writeSQLCAGRP() is called with no SQLException (null) there is no attempt to put an
internationalized error message into the outgoing message (The third argument to writeSQLCAXGRP()
is null). This is reasonable, but the same optimization is not done when the exception is
one of the dummy exceptions mentioned previously. In this case an internationalized version
of the message "End of Data" is constructed and inserted into the message.  It would be better
to call writeSQLCAXGRP(..,null,..) in this case as well, since it isn't needed by the client
in this case.
> Finally, writeSQLCAERRWARN() uses writeScalarPaddedBytes() to write values that also
can be stored as byte[] constants, and written faster with writeBytes()

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message