On Aug 5, 2:12 pm, Evan Jones <ev...@mit.edu> wrote:
> On Aug 5, 2010, at 7:06 , Ralf wrote:
> > 1. CodedInputStream uses an internal byte buffer, instead of
> > directly using the InputStream. Does this give significant performance
> > improvements?
> It does appear to, actually. I tried it with CodedOutputStream, but
> the issues should be the same. The issue is that CodedOutputStream
> produces output a byte at a time. It is significantly faster to do raw
> array accesses than to call out to OutputStream each time. I no longer
> have this code, but here is a post I made about my experiment:
Thanks, this is useful.
> > 2. Messages implement the method getSerializedSize(). Is this used for
> > anything other than for serializing the message? Are there any
> > alternative implementations you considered, that does not depend on
> > pre-computing the size?
> The protocol buffer format requires this, since the messages are not
> self delimiting. That is, to serialize them you need to prepend the
> length. The alternative would require a special "end of message"
> marker. I think the reason this seems less appealing is that you then
> need to "escape" this special marker in the output (eg. if it appears
> in an embedded byte string), but I'm just guessing here.
I might be mistaken, but didn't "groups" use this approach - use a
special tag to indicate the end of a message? As only tags are
checked, there is no need to escape any data.
Anyway, I was referring more to the implementation. For example, we
could first serialize the message to a ByteArrayOutputStream, then
write the result and its size to the output. Obviously this approach
is much slower, but I was wondering if there were other similar
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