You could reconstruct the stream every N bytes, where N << limit.

But I doubt there is really much overhead in constructing a new
CodedInputStream on the stack for each message.  No heap space is allocated
in the process.

I'd also be amenable to a method which resets the bytes counter.

What we really need is a MessageStream class which handles this kind of
stuff at a higher level, but I haven't gotten around to writing such a
thing.

On Thu, Jun 17, 2010 at 2:10 PM, Evan Jones <ev...@mit.edu> wrote:

> On Jun 17, 2010, at 17:05 , Evan Jones wrote:
>
>> I'm working around this by moving the CodedInputStream inside my loop,
>> which is fine, but seems sub-optimal. At the very least, since I have lots
>> of small messages, this means my ZeroCopyInputStream's methods get called
>> many times.
>>
>
> Based on previous mailing list discussions, this is the recommend way to do
> this. I don't care enough at the moment to test it, but it seems like using
> a single CodedInputStream for many small messages would be more efficient.
> Maybe at some point I'll try some benchmarks, but for now I'll ignore this.
>
>
> Evan
>
> --
> Evan Jones
> http://evanjones.ca/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Protocol Buffers" group.
> To post to this group, send email to proto...@googlegroups.com.
> To unsubscribe from this group, send email to
> protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to 
protobuf+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to