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  


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 protobuf@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to