[
https://issues.apache.org/jira/browse/DERBY-5068?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13026908#comment-13026908
]
Knut Anders Hatlen commented on DERBY-5068:
-------------------------------------------
Thanks for taking a look at the patch, Dag! I agree that there should be more
comments in the final patch, if we go for this approach. I don't know the
answer to your question about surrogate pairs, that's one of the things that
will need to be double checked and tested. My understanding, though, is that
Java's UTF-8 encoding algorithm treats surrogate pairs as two separate
characters, which would mean that there's no need for special handling of
surrogate pairs in the patch.
One alternative way to get rid of the intermediate objects would be to use a
CharsetEncoder (like we did on the server side in DERBY-2936) which performs
the encoding directly into a buffer. This would hide the complexity of doing
the actual encoding. However, a CharsetEncoder works on ByteBuffer and
CharBuffer objects, whereas the CcidManager interface works on String and
byte[] objects, so this would mean changing the interface and the code that
uses it. (We could of course wrap the strings and byte arrays using
ByteBuffer.wrap() and CharBuffer.wrap() within the methods to keep the
interface the same, but then we're back into the business of generating
intermediate objects, and my quick and dirty experiments suggest that this
wouldn't give any improvements compared to the current situation.)
> Investigate increased CPU usage on client after introduction of UTF-8
> CcsidManager
> ----------------------------------------------------------------------------------
>
> Key: DERBY-5068
> URL: https://issues.apache.org/jira/browse/DERBY-5068
> Project: Derby
> Issue Type: Task
> Affects Versions: 10.7.1.1
> Reporter: Knut Anders Hatlen
> Attachments: d5068-1a.diff
>
>
> While looking at the performance graphs for the single-record select test
> during the last year -
> http://home.online.no/~olmsan/derby/perf/select_1y.html - I noticed that
> there was a significant increase (10-20%) in CPU usage per transaction on the
> client early in October 2010. To be precise, the increase seems to have
> happened between revision 1004381 and revision 1004794. In that period, there
> were three commits: two related to DERBY-4757, and one related to DERBY-4825
> (tests only).
> We should try to find out what's causing the increased CPU usage and see if
> there's some way to reduce it.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
