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 <[email protected] > <mailto:[email protected]>> 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
