This might be a "how long is a piece of string"-type question, but I
was wondering if there's any way for me to know how much protocol
buffers might add to my app's memory footprint, when I have a large
number of messages. I see there's a LITE option which sounds like the
mode I would need to be working in? I'm assuming this affects the code
generational aspects of PB, ie the classes it generates for me. Is
there a runtime engine for PB?

The context of my question, is that I am currently working on a
project that uses SOAP as an IPC mechanism. I know, the decision to
use SOAP pre-dates my involvement, but our interface is quite large,
e.g. 7 main services each exposing say 10 functions, and the "client
end" is also a SOAP server for async callback, so there's an API in
both directions so-to-speak. Server end is a Java app. Between SOAP,
jetty, the generated classes etc, this IPC layer of the server end of
our app represents about a 1/3 of the runtime memory footprint of this
server process. For us, whatever we replace SOAP with would have to
have a much smaller memory footprint, rather than necessarily being
much faster.

I know Protocol Buffers doesn't include an RPC implementation and
merely provides stubs, but I could imagine we could produce a fairly
light-weight RPC implementation, but I'm more concerned that we could
go down this road and find that using Protocol Buffers will also
produce a large memory footprint, really because our API is large. I'm
not sure if this gives enough context to help anyone answer my
question, but I would be interested even in understanding a little
more about how I might go about working this out for myself? Any
pointers would be appreciated.

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