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, <wayne.mene...@gmail.com> 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 email@example.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---