[
https://issues.apache.org/jira/browse/DERBY-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912480#action_12912480
]
Knut Anders Hatlen commented on DERBY-4746:
-------------------------------------------
The new logic in the patch looks correct to me, but the writeRDBNAM() method is
a bit too aggressive on allocating byte arrays:
1)
+ int len = currentManager.getByteLength(rdbnam);
The UTF-8 CCSID manager will allocate a new byte array in order to find the
length, and then throw it away.
2)
+ /* Initialize the buffer at MAX_NAME - max length in bytes for RDBNAM
*/
+ ByteBuffer buff = ByteBuffer.allocate(CodePoint.MAX_NAME);
This will allocate a byte buffer with length 255, but after DERBY-4805 it'll
increase to ~64K, and then it's probably going to hurt.
3)
+ /* Convert the RDBNAM into bytes using the current CCSID */
+ currentManager.convertFromJavaString(rdbnam, buff);
Here, the UTF-8 CCSID manager will allocate a new byte array again, holding the
contents of the string, before it puts it into the ByteBuffer.
4)
+ /* Get the byte array out of the byte buffer */
+ int bytesLen = buff.position();
+ byte[] rdbBytes = new byte[bytesLen];
And here yet another byte array is allocated before it's sent to DDMWriter.
I think if writeRDBNAM() had used writeScalarPaddedString() instead of
writeScalarPaddedBytes(), we could avoid some of these byte array allocations.
We wouldn't avoid all of them, because writeScalarPaddedString() would still
call getByteLength() and convertFromJavaString() internally, but at least 2 and
4 would go away.
As a possible future improvement, we may also consider changing
Utf8CcsidManager's implementation of convertFromJavaString(String,ByteBuffer)
and getByteLength() so that they don't create any byte arrays internally.
> (Server) Implement UTF8 support on DRDA
> ---------------------------------------
>
> Key: DERBY-4746
> URL: https://issues.apache.org/jira/browse/DERBY-4746
> Project: Derby
> Issue Type: Sub-task
> Affects Versions: 10.7.0.0
> Reporter: Tiago R. Espinha
> Assignee: Tiago R. Espinha
> Fix For: 10.7.0.0
>
> Attachments: DERBY-4746.diff, DERBY-4746.diff, DERBY-4746.diff,
> DERBY-4746_p2-impl.diff, DERBY-4746_p2-impl.diff, DERBY-4746_p2-tests.diff,
> DERBY-4746_p2-tests.diff, DERBY-4746_p3.diff, DERBY-4746_p3.diff,
> DERBY-4746_p3.diff, TestClient.java
>
>
> I'm branching out this issue into server and client changes. Since the
> changes are incremental and small, DERBY-728 would soon become confusing if
> it had to bear the patches for both server and client.
> For future reference, some patches have actually been applied in DERBY-728.
> These **ARE** also required for the server implementation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
