db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5068) Investigate increased CPU usage on client after introduction of UTF-8 CcsidManager
Date Fri, 29 Apr 2011 08:48:03 GMT

    [ 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:
>            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

View raw message