[ http://issues.apache.org/jira/browse/DERBY-825?page=all ]
Dyre Tjeldvoll updated DERBY-825:
---------------------------------
Attachment: derby-825.stat
derby-825.diff
derbynetclientmats_report.txt
derbynetclientmats had 3 failures also seen in nightly testing. derbynetmats
had no failures.
> writeSQLCAGRP() should use byte[] constants instead of Strings where feasible
> -----------------------------------------------------------------------------
>
> Key: DERBY-825
> URL: http://issues.apache.org/jira/browse/DERBY-825
> Project: Derby
> Type: Sub-task
> Components: Network Server, Performance
> Reporter: Dyre Tjeldvoll
> Assignee: Dyre Tjeldvoll
> Priority: Minor
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
