> Probably because in Java we use ByteString to represent bytes fields so 
you will most likely use only readBytes() rather than readRawBytes(int). 

ByteString & CodedInputStream.readBytes() have the same problem ... every 
invocation allocates a new byte[] from the heap

CodedInputStream.readBytes() calls static ByteString.copyFrom(...)
All implementations of ByteString.copyFrom(...) end up allocating a new 
byte[] from the heap


> We have been working on some optimizations in CodedInputStream to 
eliminate unnecessary bytes copy but you won't see it until next major 
opensource release.

ok


Thank you for taking the time to respond. 

Michael

On Friday, July 12, 2013 5:28:47 PM UTC-4, Feng Xiao wrote:
>
>
> On Fri, Jul 12, 2013 at 6:26 AM, Michael Howard 
> <mic...@howards.org<javascript:>
> > wrote:
>
>> I am a protocol buffer newbie. 
>> I have inherited a performance-critical application that reads some 
>> high-volume data streams that are coded in protocol buffer format. 
>>
>> byte[] org.google.protobuf.CodedInputStream.readRawBytes(int size)
>> allocates a new byte[size] from the heap on every call. 
>>
>> I want to avoid this heap allocation. 
>>
>> There is no method that allows one to pass in their own byte[] buf to 
>> avoid allocating a new byte[size] from a the heap on each invocation. 
>>
>> In addition, the class is declared final ... which prevents one from 
>> deriving a subclass and implementing readRawBytes(int size, byte[] buf)
>>
>> This prevents me from adding this "heap friendly" change without cloning 
>> & modifying the source code. 
>>
>> Q: Am I missing something? 
>>
>> Q: What was the thinking/rationale behind these design decisions? 
>>
> Probably because in Java we use ByteString to represent bytes fields so 
> you will most likely use only readBytes() rather than readRawBytes(int). 
> Therefore no one has tried to optimized the code for the byte[] case. It's 
> changing though. We have been working on some optimizations in 
> CodedInputStream to eliminate unnecessary bytes copy but you won't see it 
> until next major opensource release.
>  
>
>>
>>
>> Thanks,
>> Michael
>>
>>  -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Protocol Buffers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to protobuf+u...@googlegroups.com <javascript:>.
>> To post to this group, send email to prot...@googlegroups.com<javascript:>
>> .
>> Visit this group at http://groups.google.com/group/protobuf.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to protobuf+unsubscr...@googlegroups.com.
To post to this group, send email to protobuf@googlegroups.com.
Visit this group at http://groups.google.com/group/protobuf.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to