[ https://issues.apache.org/jira/browse/THRIFT-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14711504#comment-14711504 ]
ASF GitHub Bot commented on THRIFT-3306: ---------------------------------------- GitHub user evanj opened a pull request: https://github.com/apache/thrift/pull/596 THRIFT-3306: Java: TBinaryProtocol: Use a single temp byte[] buffer Reduces allocations and GC when TBinaryProtocol is allocated repeatedly. Originally separate byte[] arrays were allocated for each integer type, and a separate array for input and output. However, one buffer of the largest size (8 bytes for i64) can be used for all purposes. You can merge this pull request into a Git repository by running: $ git pull https://github.com/evanj/thrift THRIFT-3306 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/thrift/pull/596.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #596 ---- commit 73486e21a4028418ed606b5f9f4709cad20b32fe Author: Evan Jones <ejo...@twitter.com> Date: 2015-08-25T15:51:07Z THRIFT-3306: Java: TBinaryProtocol: Use a single temp byte[] buffer Reduces allocations and GC when TBinaryProtocol is allocated repeatedly. Originally separate byte[] arrays were allocated for each integer type, and a separate array for input and output. However, one buffer of the largest size (8 bytes for i64) can be used for all purposes. ---- > Java: TBinaryProtocol: Use 1 temp buffer instead of allocating 8 > ---------------------------------------------------------------- > > Key: THRIFT-3306 > URL: https://issues.apache.org/jira/browse/THRIFT-3306 > Project: Thrift > Issue Type: Improvement > Reporter: Evan Jones > Priority: Minor > > TBinaryProtocol has a member buffer for reading and for serializing each of > the integer types. It can get by with only a single one: 8 bytes long for the > maximum length integer. This causes a significant reduction in allocations > and GC in cases that create the TBinaryProtocol to serialize a single > message, instead of reusing it. > This passes "ant test". I ran the existing SerializationBenchmark and there > is no statistically significant difference (the average of 5 runs is smaller > on my machine, but I don't think we should read much into that). > I have a JMH benchmark for this, and it shows that when the TBinaryProtocol > is allocated each time, this change is better, but is more or less the same > when you reuse the TBinaryProtocol in a loop. -- This message was sent by Atlassian JIRA (v6.3.4#6332)