Actually, optimize_for = SPEED is now the default (as of 2.1.0).  (If there
is still documentation somewhere saying otherwise, point me at it so I can
fix it.)
The other option is optimize_for = CODE_SIZE.  Protocol buffer generated
code can be surprisingly large -- we've seen binaries at google that have
literally tens or even hundreds of megabytes of protocol buffer code when
compiled.  Optimizing for code size cuts generated code by over half but is
significantly slower.  It should be used whenever you do not need blindingly
fast performance.

In the next version there will be a third option:  LITE_RUNTIME.  This
variant is like optimizing for speed but will generate code that only
depends on a lighter version of the protobuf runtime library that does not
include descriptors or reflection.  For apps that have a small number of
protocol types, this can save more total code space than optimizing for code
size, since the regular runtime library is rather large.  However,
optimizing for both code size and lite runtime is impossible since the lite
runtime does not include reflection, which is needed for the normal code
size optimizations to work.  My hope is that this variant will be more
useful for embedded platforms and mobile devices.

All of these options apply to C++ and Java only.

On Mon, Jun 8, 2009 at 2:03 PM, <> wrote:

> Hi,
> Can anyone tell me what are the caveats of using the option
> optimize_for = SPEED; during code generation?
> The documentation says it can improve parsing and serialization. But
> what are the cons of using this?
> Thanks,
> Wayne
> >

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to