[
https://issues.apache.org/jira/browse/THRIFT-765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863458#action_12863458
]
Bryan Duxbury commented on THRIFT-765:
--------------------------------------
Firstly, as far as I can tell, the built-in Java version is *not* implemented
in C. I don't know all of the reasons why it's faster, but a few of them are:
avoid byte array allocation/copy, more specific implementation, and less
modular code with fewer intermediate layers.
It seems like many other projects that do UTF-8 encoding do so via a custom
method, some better than others. I'll admit it's tricky, but the performance
benefit is so huge that I'm willing to pursue it more deeply.
> Improved string encoding and decoding performance
> -------------------------------------------------
>
> Key: THRIFT-765
> URL: https://issues.apache.org/jira/browse/THRIFT-765
> Project: Thrift
> Issue Type: Improvement
> Components: Library (Java)
> Affects Versions: 0.2
> Reporter: Bryan Duxbury
> Assignee: Bryan Duxbury
> Fix For: 0.4
>
> Attachments: thrift-765-redux-v2.patch, thrift-765-redux.patch,
> thrift-765.patch
>
>
> One of the most consistent time-consuming spots of Thrift serialization and
> deserialization is string encoding. For some inscrutable reason,
> String.getBytes("UTF-8") is slow.
> However, it's recently been brought to my attention that DataOutputStream's
> writeUTF method has a faster implementation of UTF-8 encoding and decoding.
> We should use this style of encoding.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
