Have you considered refactoring your compiler into the form of a code generator plugin? Then you would not have to maintain your own parser anymore, you'd get the .zip output feature for free, and you could add insertion points to your code for someone else to extend it to support an RPC system.
On Sat, Jan 16, 2010 at 7:47 AM, Chris Kuklewicz <turingt...@gmail.com>wrote: > A question for Kenton or someone else who may know: Since repeated > fields can be read as packed or unpacked, does the packed serializer > ever use the unpacked format when it would be more efficient? Saving a > single packed datum is more verbose then a single unpacked datum. > No, the official implementations do not do this. A couple arguments against: - People who have to interact with pre-2.3.0 code cannot use such an optimization, so it would have to be optional, which it probably isn't worth. - The optimization you describe would only be useful in the one-element case, and in that case it would only save one byte. Since this case is probably relatively unlikely for packed repeated fields (which are typically large), the extra overhead of simply checking for this case probably isn't worth the savings it would bring.--
You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
To post to this group, send email to proto...@googlegroups.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.
