On Oct 22, 2009, at 16:36 , Kenton Varda wrote:
> You note that small messages seem faster with smaller buffer sizes,
> but larger messages are slower. I am guessing that by "small
> messages" you mean ones which are significantly smaller than the
> buffer size, and "large messages" means larger than the buffer size.
Right. I just used the messages and benchmark framework in SVN:
The small message is 228 bytes, the large message is 82.6 kB
> One thing you might try: if the message is smaller than 4096 (or
> whatever the buffer size constant is), then allocate a buffer
> exactly as big as the message to avoid waste. You can call
> getSerializedSize() to find out the message size ahead of time.
> Note that calling this doesn't actually waste any time since the
> result is cached, and it would have to be called during
> serialization anyway.
That is a good idea. This would be a tiny patch to the
AbstractMessageLite.writeTo(OutputStream). It already effectively does
this for toByteString() and toByteArray(), but doing this for
writeTo(OutputStream) would probably be a win: either it uses the
JDK's preferred buffer size for big messages, which would halve the
number of calls to .write(), or would use an exact sized buffer for
smaller messages, which (should? might?) result in reduced garbage
collection. I'll put testing this on my TODO list. It is a trivial
code change, but benchmarking it carefully takes time.
Basically this all started because I was curious how many times my
data was being copied between a protocol message and the wire. I
should eventually try some of these tweaks on a "larger" application
that is doing network I/O, so I'll eventually do some digging in that
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
For more options, visit this group at