[
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 <[email protected]>
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)
