[
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: 10.1.2.1
> Reporter: Dyre Tjeldvoll
> Assignee: Dyre Tjeldvoll
> Priority: Minor
> Fix For: 10.1.3.1
>
> 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.
