[ http://issues.apache.org/jira/browse/DERBY-825?page=all ]
     
Dyre Tjeldvoll closed DERBY-825:
--------------------------------


Committed by Bernt Johnsen

> 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

Reply via email to