You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dyre Tjeldvoll (JIRA)" <de...@db.apache.org> on 2006/01/19 09:20:42 UTC
[jira] Created: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
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
Reporter: Dyre Tjeldvoll
--
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
[jira] Resolved: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by "Bernt M. Johnsen (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-825?page=all ]
Bernt M. Johnsen resolved DERBY-825:
------------------------------------
Resolution: Fixed
Comitted as #370806 Fri Jan 20 14:34:53 CET 2006 bernt
The log message errouneous and ended up under DERBY-815.
> 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
[jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by "Dyre Tjeldvoll (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-825?page=all ]
Dyre Tjeldvoll updated DERBY-825:
---------------------------------
Fix Version: 10.1.3.0
Version: 10.1.2.1
Setting fixin to 10.1.3.0. But is not extremely important so it could be posponed if it is difficult to merge.
> 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
> Versions: 10.1.2.1
> Reporter: Dyre Tjeldvoll
> Assignee: Dyre Tjeldvoll
> Priority: Minor
> Fix For: 10.1.3.0
> 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
Re: [jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
I have reviewed and am testing this patch. I think it is "worthy" for
committ, but I have one question:
Dyre: Do you want to pursue Bryan's proposal now or do you think we
should committ and file Bryan's propsal as a (near) future
improvement?
>>>>>>>>>>>> Knut Anders Hatlen wrote (2006-01-20 09:22:28):
> Bryan Pendleton <bp...@amberpoint.com> writes:
>
> > Dyre Tjeldvoll (JIRA) wrote:
> >>> A solution is to keep the commonly used SQLStates as byte[] constants that can be inserted into the message with writeBytes().
> >
> > I think that the solution shows great promise, but the patch
> > that you provided seems too "open coded" for me.
> >
> > It seems to me that the recently-added DRDAString class could
> > be used as the encapsulation vehicle for this String/byte[]
> > caching stuff, so that the bulk of the DRDA code didn't have
> > to be so involved in the details of when to use the string and
> > when to use the byte array.
> >
> > So instead of seeing a bunch of changes like:
> >
> > - writer.writeString(server.prdId);
> > + // Write the byte[] constant rather than the string, for efficiency
> > + writer.writeBytes(server.prdIdBytes_);
> >
> > which seems to mean that we'd have to maintain constant vigilance
> > into the future to make sure that we know when to use the String
> > versus when to use the byte[], it seems like we should turn an
> > object like server.prdId into a DRDAString, and then let DDMWriter
> > and DRDAString work out the details themselves about whether to use
> > the String or the byte[].
> >
> > Does this make any sense? Am I barking up the wrong tree?
>
> It makes sense, but DRDAString uses a CcsidManager to convert between
> byte[] and String. Currently, the only implementation of CcsidManager
> is for ebcdic, while the message Dyre is working on is sent in UTF-8,
> I think. In that case we need a UTF8CcsidManager.
>
> --
> Knut Anders
>
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: [jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Bryan Pendleton <bp...@amberpoint.com> writes:
> Dyre Tjeldvoll (JIRA) wrote:
>>> A solution is to keep the commonly used SQLStates as byte[] constants that can be inserted into the message with writeBytes().
>
> I think that the solution shows great promise, but the patch
> that you provided seems too "open coded" for me.
>
> It seems to me that the recently-added DRDAString class could
> be used as the encapsulation vehicle for this String/byte[]
> caching stuff, so that the bulk of the DRDA code didn't have
> to be so involved in the details of when to use the string and
> when to use the byte array.
>
> So instead of seeing a bunch of changes like:
>
> - writer.writeString(server.prdId);
> + // Write the byte[] constant rather than the string, for efficiency
> + writer.writeBytes(server.prdIdBytes_);
>
> which seems to mean that we'd have to maintain constant vigilance
> into the future to make sure that we know when to use the String
> versus when to use the byte[], it seems like we should turn an
> object like server.prdId into a DRDAString, and then let DDMWriter
> and DRDAString work out the details themselves about whether to use
> the String or the byte[].
>
> Does this make any sense? Am I barking up the wrong tree?
It makes sense, but DRDAString uses a CcsidManager to convert between
byte[] and String. Currently, the only implementation of CcsidManager
is for ebcdic, while the message Dyre is working on is sent in UTF-8,
I think. In that case we need a UTF8CcsidManager.
--
Knut Anders
Re: [jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
Ok. I'll commit this one.
>>>>>>>>>>>> Dyre.Tjeldvoll@Sun.COM wrote (2006-01-20 14:15:34):
> >>>>> "BP" == Bryan Pendleton <bp...@amberpoint.com> writes:
>
> BP> Dyre Tjeldvoll (JIRA) wrote:
> >>> A solution is to keep the commonly used SQLStates as byte[] constants that can be inserted into the message with writeBytes().
>
> BP> I think that the solution shows great promise, but the patch
> BP> that you provided seems too "open coded" for me.
>
> BP> It seems to me that the recently-added DRDAString class could
> BP> be used as the encapsulation vehicle for this String/byte[]
> BP> caching stuff, so that the bulk of the DRDA code didn't have
> BP> to be so involved in the details of when to use the string and
> BP> when to use the byte array.
>
> BP> So instead of seeing a bunch of changes like:
>
> BP> - writer.writeString(server.prdId);
> BP> + // Write the byte[] constant rather than the string, for efficiency
> BP> + writer.writeBytes(server.prdIdBytes_);
>
> BP> which seems to mean that we'd have to maintain constant vigilance
> BP> into the future to make sure that we know when to use the String
> BP> versus when to use the byte[], it seems like we should turn an
> BP> object like server.prdId into a DRDAString, and then let DDMWriter
> BP> and DRDAString work out the details themselves about whether to use
> BP> the String or the byte[].
>
> BP> Does this make any sense? Am I barking up the wrong tree?
>
> I see your point, and was thinking along these lines for a while. I
> was thinking about making a String replacement that kept a String and
> a byte[] internally and did the conversion on demand and cached the
> result.
>
> But then I decided that such a solution would provide much more
> functionality than what was needed. Keep in that these values are in
> fact constants, and they are not used for anything other than filling
> messages, and so, unlike DRDAStrings, they don't need a String
> interface. The DRDAStrings need to work as Strings AND be compared
> efficiently to a segment of a byte array.
>
> I see that such a WrapperString clould be useful for future work, but
> it also has its problems. Using a replacement for String is tedious
> since you cannot extend the String class. You have to create a wrapper
> (like DRDAString) and change the signature of every method that
> takes a String argument to take the WrapperString as argument. And
> frequently you'll still need to provide an overload for String as
> well.
>
> Also, if you want to be able to use your String replacement generally
> you have to come up with a place to put it. And as the "sharing common
> code" discussions have shown, that is not always as easy as it
> sounds...
>
> To conclude, I will not implment and use such a data type for this
> patch (it is not my itch), but others should feel free to do so.
>
> (For the record, I would not have replaced Strings with byte[], if was
> not for the fact that the profiler told me that this was a hotspot)
>
>
> --
> dt
>
> However, experience shows that for many people and many applications a
> dose of paranoia is reasonable - Bjarne Stroustrup
>
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: [jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by Dy...@Sun.COM.
>>>>> "BP" == Bryan Pendleton <bp...@amberpoint.com> writes:
BP> Dyre Tjeldvoll (JIRA) wrote:
>>> A solution is to keep the commonly used SQLStates as byte[] constants that can be inserted into the message with writeBytes().
BP> I think that the solution shows great promise, but the patch
BP> that you provided seems too "open coded" for me.
BP> It seems to me that the recently-added DRDAString class could
BP> be used as the encapsulation vehicle for this String/byte[]
BP> caching stuff, so that the bulk of the DRDA code didn't have
BP> to be so involved in the details of when to use the string and
BP> when to use the byte array.
BP> So instead of seeing a bunch of changes like:
BP> - writer.writeString(server.prdId);
BP> + // Write the byte[] constant rather than the string, for efficiency
BP> + writer.writeBytes(server.prdIdBytes_);
BP> which seems to mean that we'd have to maintain constant vigilance
BP> into the future to make sure that we know when to use the String
BP> versus when to use the byte[], it seems like we should turn an
BP> object like server.prdId into a DRDAString, and then let DDMWriter
BP> and DRDAString work out the details themselves about whether to use
BP> the String or the byte[].
BP> Does this make any sense? Am I barking up the wrong tree?
I see your point, and was thinking along these lines for a while. I
was thinking about making a String replacement that kept a String and
a byte[] internally and did the conversion on demand and cached the
result.
But then I decided that such a solution would provide much more
functionality than what was needed. Keep in that these values are in
fact constants, and they are not used for anything other than filling
messages, and so, unlike DRDAStrings, they don't need a String
interface. The DRDAStrings need to work as Strings AND be compared
efficiently to a segment of a byte array.
I see that such a WrapperString clould be useful for future work, but
it also has its problems. Using a replacement for String is tedious
since you cannot extend the String class. You have to create a wrapper
(like DRDAString) and change the signature of every method that
takes a String argument to take the WrapperString as argument. And
frequently you'll still need to provide an overload for String as
well.
Also, if you want to be able to use your String replacement generally
you have to come up with a place to put it. And as the "sharing common
code" discussions have shown, that is not always as easy as it
sounds...
To conclude, I will not implment and use such a data type for this
patch (it is not my itch), but others should feel free to do so.
(For the record, I would not have replaced Strings with byte[], if was
not for the fact that the profiler told me that this was a hotspot)
--
dt
However, experience shows that for many people and many applications a
dose of paranoia is reasonable - Bjarne Stroustrup
Re: [jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by Bryan Pendleton <bp...@amberpoint.com>.
Dyre Tjeldvoll (JIRA) wrote:
>> A solution is to keep the commonly used SQLStates as byte[] constants that can be inserted into the message with writeBytes().
I think that the solution shows great promise, but the patch
that you provided seems too "open coded" for me.
It seems to me that the recently-added DRDAString class could
be used as the encapsulation vehicle for this String/byte[]
caching stuff, so that the bulk of the DRDA code didn't have
to be so involved in the details of when to use the string and
when to use the byte array.
So instead of seeing a bunch of changes like:
- writer.writeString(server.prdId);
+ // Write the byte[] constant rather than the string, for efficiency
+ writer.writeBytes(server.prdIdBytes_);
which seems to mean that we'd have to maintain constant vigilance
into the future to make sure that we know when to use the String
versus when to use the byte[], it seems like we should turn an
object like server.prdId into a DRDAString, and then let DDMWriter
and DRDAString work out the details themselves about whether to use
the String or the byte[].
Does this make any sense? Am I barking up the wrong tree?
thanks,
bryan
[jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by "Dyre Tjeldvoll (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Reopened: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by "Dyre Tjeldvoll (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-825?page=all ]
Dyre Tjeldvoll reopened DERBY-825:
----------------------------------
Reopen to set fixin
> 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
[jira] Updated: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by "Dyre Tjeldvoll (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Closed: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by "Dyre Tjeldvoll (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-825?page=all ]
Dyre Tjeldvoll closed DERBY-825:
--------------------------------
Resolution: Fixed
> 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
> Versions: 10.1.2.1
> Reporter: Dyre Tjeldvoll
> Assignee: Dyre Tjeldvoll
> Priority: Minor
> Fix For: 10.1.3.0
> 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
[jira] Closed: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by "Dyre Tjeldvoll (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Assigned: (DERBY-825) writeSQLCAGRP() should use byte[]
constants instead of Strings where feasible
Posted by "Dyre Tjeldvoll (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-825?page=all ]
Dyre Tjeldvoll reassigned DERBY-825:
------------------------------------
Assign To: Dyre Tjeldvoll
> 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
> Reporter: Dyre Tjeldvoll
> Assignee: Dyre Tjeldvoll
>
--
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