On Fri, Dec 5, 2008 at 10:59 PM, Alek Storm <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 3, 2008 at 5:32 AM, Kenton Varda <[EMAIL PROTECTED]> wrote: > >> Sorry, I think you misunderstood. The C++ parsers generated by protoc >> (with optimize_for = SPEED) are an order of magnitude faster than the >> dynamic *C++* parser (used with optimize_for = CODE_SIZE and >> DynamicMessage). The Python parser is considerably slower than either of >> them, but that's beside the point. Your "decoupled" parser which produces a >> tag/value tree will be at least as slow as the existing C++ dynamic parser, >> probably slower (since it sounds like it would use some sort of dictionary >> structure rather than flat classes/structs). >> > > Oh, I forgot we have two C++ parsers. The method I described uses the > generated (SPEED) parser, so it should be a great deal quicker. It just > outputs a tree instead of a message, leaving the smart object creation to > Python. > No, the static (SPEED) parser parses to generated C++ objects. It doesn't make sense to say that we'll use the static parser to parse to this abstract "tree" structure, because the whole point of the static parser is that it parses to concrete objects. If it didn't, it wouldn't be so fast. (In fact, the biggest bottleneck in protobuf parsing is memory bandwidth, and I can't see how your "tree" structure would be anywhere near as compact as a generated message class.) But then, protobuf objects might as well be your "tree". There's no reason to define a separate "tree" structure when we already have a structure explicitly designed for holding protocol buffer data. Your "tree" probably would not be any easier to access than an actual protocol message object. > Honestly, I think using reflection for something as basic as changing the > ouput format is hackish and could get ugly. > I think you're thinking of a different kind of reflection. I'm talking about the google::protobuf::Reflection interface. The whole point of this interface is to allow you to do things like write custom codecs for things like JSON or XML. Take a look at text_format.cc for an example usage. > But just for the record, I'm pretty sure Python's list remove() method > compares by value, and doesn't have a method that compares by identity. So > there would be no reason to include a compare-by-identity method in protobuf > repeated fields. > OK, well, honestly, I think a remove-by-value makes even less sense. Comparing large non-flat data structures by value is awkward and rarely useful. But this is exactly the kind of thing that we don't know if we don't have a use case to examine. > Okay, you place more value on "compact interface". So are we keeping > remove() for scalar values? I think their interfaces should be consistent, > but I don't think you think that's as important. remove() makes sense for scalars. There's no question of identity vs. value comparison, and it's not awkward or unusual to compare two scalar values. > Okay. So let's say we have a pure-C++ parser with a Python wrapper. This > brings us back to getting slicing to work in C++ with no garbage collector. > Kenton, could you elaborate on what you meant earlier by "ownership > problems" specific to the C++ version? I can't really see anything that > would affect PB repeated fields that isn't taken care of by handing the user > control over allocation and deallocation of the field elements. If a message Foo has a repeated field of type Bar, then the Bar objects in that field are owned by Foo. When you delete Foo, all the Bars are deleted. Leaving it up to the user to delete the Bar objects themselves is way too much of a burden. > Is there anything wrong with having a list of parents? I'm guessing I'm > being naive - would speed be affected too much by that? Way too complicated, probably a lot of overhead, and not very useful in practice. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
