[ 
https://issues.apache.org/jira/browse/THRIFT-4555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16440479#comment-16440479
 ] 

ASF GitHub Bot commented on THRIFT-4555:
----------------------------------------

bpodgursky commented on issue #1540: THRIFT-4555 Optionally disable copies of 
binary fields in Java constructors, getters, and setters
URL: https://github.com/apache/thrift/pull/1540#issuecomment-381864455
 
 
   Thanks!

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Getter of binary field in Java creates unnecessary copy
> -------------------------------------------------------
>
>                 Key: THRIFT-4555
>                 URL: https://issues.apache.org/jira/browse/THRIFT-4555
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Java - Compiler
>    Affects Versions: 0.11.0
>            Reporter: Joel Croteau
>            Priority: Minor
>             Fix For: 0.12.0
>
>
> The get[field] method in generated Java code generates a new copy of a binary 
> field every time it is called. This seems incredibly inefficient. Take a 
> simple example struct:
> {code:java}
> struct StructWithBinary {
>        1: required binary field;
> }
> {code}
> a portion of the generated code for this is:
> {code:java}
>   public byte[] getField() {
>     setField(org.apache.thrift.TBaseHelper.rightSize(field));
>     return field == null ? null : field.array();
>   }
> ...
>   public StructWithBinary setField(java.nio.ByteBuffer field) {
>     this.field = org.apache.thrift.TBaseHelper.copyBinary(field);
>     return this;
>   }
> {code}
> So whenever getField is called, setField calls copyBinary and generates 
> another copy. This adds quite a lot of overhead to the getter here and should 
> be fixed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to