[
https://issues.apache.org/jira/browse/THRIFT-1058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035651#comment-13035651
]
Bryan Duxbury commented on THRIFT-1058:
---------------------------------------
What's the objection to slice()ing the buffers at use time? If it's already
positioned at zero, then it won't cause any problems.
@Jeff - your own numbers show 20% overhead, which, while not the 100% I
reported earlier, is nothing to ignore. (We've worked hard to get less than 20%
in the past.)
> All ByteBuffers the client uses should be slice()ed
> ---------------------------------------------------
>
> Key: THRIFT-1058
> URL: https://issues.apache.org/jira/browse/THRIFT-1058
> Project: Thrift
> Issue Type: Bug
> Affects Versions: 0.6
> Reporter: ryan rawson
> Attachments: ByteBufferTest.java
>
>
> Right now the code does something like yay so:
> return ByteBuffer.wrap(array, pos, len);
> The only problem is that .wrap(byte[],int,int) returns a ByteBuffer with
> position equal to pos and limit set to pos+len. Which means users cant used
> 'rewind' or position(0).
> It would be cleaner if the contract was "ByteBuffers will have position=0,
> limit=how much data you have".
> The way to accomplish this would be to:
> return ByteBuffer.wrap(array, pos, len).slice();
> In exchange for 1 extra object alloc (which the GC can clean up quick) we get
> the benefit of a easier to use BB interface.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
