Thanks for the reply Kenton. Another issue occurs to me as a get ready to shut off for the night. Reading repeated extension keys gets more annoying, especially for keys not known at code generation time. I will sleep on it and then maybe the details will be clear.
On 16/01/2010 20:32, Kenton Varda wrote: > 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 > <mailto: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.
