[ https://issues.apache.org/jira/browse/THRIFT-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14711559#comment-14711559 ]
Evan Jones commented on THRIFT-3306: ------------------------------------ Happy to share my JMH benchmark code, but here are some results with a small test object containing a few strings, a list of strings, one i64 and one bool. Original, New Protocol/Transport: 896105.405 ±(99.9%) 2279.918 ops/s Change, New Protocol/Transport: 952790.311 ±(99.9%) 3762.642 ops/s Original, Reuse Protocol/Transport: 1333528.752 ±(99.9%) 5321.679 ops/s Change, Reuse Protocol/Transport: 1339813.126 ±(99.9%) 5376.862 ops/s Java version: 1.8.0_51 > 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)