Re: field ordering
In practice we're talking on the order of a 10% performance gain from this optimization. So, it's not the end of the world if you write fields out-of-order. However, some users may rely on canonical ordering for other reasons, e.g. to be able to cryptographically sign messages, use their hashes as cache keys, etc. On Thu, Aug 20, 2009 at 9:23 AM, roger peppe wrote: > > 2009/8/20 Michael Poole : > > roger peppe writes: > >> the documentation says, on writing fields in order: "This allows > >> parsing code to use optimizations > >> that rely on field numbers being in sequence." > >> > >> what optimizations might these be? > >> does the current implementation use any such optimizations? > >> what penalty do i pay by *not* writing fields in order? > > > > The C++ generator does this. If you look at some of the generated > > MergePartialFromCodedStream() methods, you can see how this is done. > > interesting, i hadn't noticed that. > > not an easy trick to pull in a language without goto, i'd think. > > tail recursion optimisation could make it possible, i suppose, > assuming the function call was cheaper than the switch. > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: field ordering
2009/8/20 Michael Poole : > roger peppe writes: >> the documentation says, on writing fields in order: "This allows >> parsing code to use optimizations >> that rely on field numbers being in sequence." >> >> what optimizations might these be? >> does the current implementation use any such optimizations? >> what penalty do i pay by *not* writing fields in order? > > The C++ generator does this. If you look at some of the generated > MergePartialFromCodedStream() methods, you can see how this is done. interesting, i hadn't noticed that. not an easy trick to pull in a language without goto, i'd think. tail recursion optimisation could make it possible, i suppose, assuming the function call was cheaper than the switch. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: field ordering
roger peppe writes: > the documentation says, on writing fields in order: "This allows > parsing code to use optimizations > that rely on field numbers being in sequence." > > what optimizations might these be? > does the current implementation use any such optimizations? > what penalty do i pay by *not* writing fields in order? The C++ generator does this. If you look at some of the generated MergePartialFromCodedStream() methods, you can see how this is done. The code peeks at the next tag, and if it has the expected (in-sequence) value, needs only a single conditional branch to go to the correct handler. If the fields are not in order, the parser must find the correct handler through a switch statement. Due to the difficulty of predicting the path that will be taken by that switch, this can save considerable time on deeply pipelined CPUs. Michael Poole --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
