[ http://issues.apache.org/jira/browse/DERBY-825?page=all ]
Dyre Tjeldvoll updated DERBY-825:
---------------------------------
Component: Network Server
Performance
Description:
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()
Environment:
Priority: Minor (was: Major)
> 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
>
> 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
