Hmm, your bean and buffer classes sound conceptually equivalent to my builder and message classes. Regarding lazy parsing, this is certainly something we've considered before, but it introduces a lot of problems:
1) Every getter method must now first check whether the message is parsed, and parse it if not. Worse, for proper thread safety it really needs to lock a mutex while performing this check. For a fair comparison of parsing speed, you really need another benchmark which measures the speed of accessing all the fields of the message. I think you'll find that parsing a message *and* accessing all its fields is significantly slower with the lazy approach. Your approach might be faster in the case of a very deep message in which the user only wants to access a few shallow fields, but I think this case is relatively uncommon. 2) What happens if the message is invalid? The user will probably expect that calling simple getter methods will not throw parse exceptions, and probably isn't in a good position to handle these exceptions. You really want to detect parse errors at parse time, not later on down the road. We might add lazy parsing to the official implementation at some point. However, the approach we'd probably take is to use it only on fields which are explicitly marked with a "[lazy=true]" option. Developers would use this to indicate fields for which the performance trade-offs favor lazy parsing, and they are willing to deal with delayed error-checking. In your blog post you also mention that encoding the same message object multiple times without modifying it in between, or parsing a message and then serializing it without modification, is "free"... but how often does this happen in practice? These seem like unlikely cases, and easy for the user to optimize on their own without support from the protobuf implementation. On Fri, Sep 18, 2009 at 3:15 PM, hi...@hiramchirino.com <chir...@gmail.com>wrote: > > Hi Kenton, > > Your right, the reason that one benchmark has those results is because > the implementation does lazy decoding. While lazy decoding is nice, I > think that implementation has a couple of other features which are > equally as nice. See more details about it them here: > > > http://hiramchirino.com/blog/2009/09/activemq-protobuf-implemtation-features.html > > It would have hard to impossible to implement some of the stuff > without the completely different class structure it uses. I'd be > happy if it's features could be absorbed into the official > implementation. I'm just not sure how you could do that and maintain > compatibility with your existing users. > > If you have any suggestions of how we can integrate better please > advise. > > Regards, > Hiram > > On Sep 18, 12:34 pm, Kenton Varda <ken...@google.com> wrote: > > So, his implementation is a little bit faster in two of the benchmarks, > and > > impossibly faster in the other one. I don't really believe that it's > > possible to improve parsing time by as much as he claims, except by doing > > something like lazy parsing, which would just be deferring the work to > later > > on. Would have been nice if he'd contributed his optimizations back to > the > > official implementation rather than write a whole new one... > > > > On Fri, Sep 18, 2009 at 1:38 AM, ijuma <ism...@juma.me.uk> wrote: > > > > > Hey all, > > > > > I ran across the following and thought it may be of interest to this > > > list: > > > > >http://hiramchirino.com/blog/2009/09/activemq-protobuf-implementation. > .. > > > > > Best, > > > Ismael > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@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 -~----------~----~----~----~------~----~------~--~---
