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
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 Jones
> 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
> For more options, visit this group at
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
For more options, visit this group at