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 <[email protected]> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<protobuf%[email protected]> > . > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
