[protobuf] Re: Issue 198 in protobuf: Unnecessarily inefficient calculation of utf-8 encoded lengt
Comment #2 on issue 198 by ev...@mit.edu: Unnecessarily inefficient calculation of utf-8 encoded lengt http://code.google.com/p/protobuf/issues/detail?id=198 ... although this slower code path is still used for LITE and SIZE messages. It might be possible that a variant of this that properly supported surrogate pairs, could be a performance win for the LITE and SIZE messages? I would want to see some performance numbers though, but it seems to me like a scan through the string could be quite efficient, assuming that String.charAt() is cheap. -- 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.
[protobuf] Re: Issue 198 in protobuf: Unnecessarily inefficient calculation of utf-8 encoded lengt
Comment #3 on issue 198 by ken...@google.com: Unnecessarily inefficient calculation of utf-8 encoded lengt http://code.google.com/p/protobuf/issues/detail?id=198 Hmm, why did we decide not to use the cache for LITE messages? It seems like we should, but maybe I'm forgetting something? -- 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.
[protobuf] Inspect contents of a DescriptorPool object
Hi all, I'm writing a C++ library function which reads protocol buffer objects from an input stream and returns an abstract Message object to caller. When descriptors are not known at compile-time, I use a DescriptorPool::BuildFile() call to load them dynamically. I inspect each loaded file to find messages which are valid top-level objects to be parsed from my input stream (they are tagged with a custom option). However, library client may want to use objects he knows at compile- time (typically dynamic_cast'ing them, rather than getting DynamicMessage instances), so I would like to inspect the generated_pool itself to index valid descriptors it might contain. This way, I could build objects based on descriptions from generated_pool. I can't figure out how to browse a DesciptorPool (I would need a way to iterate over the whole list of FileDescriptor objects). Looking at sources, it seems it would not be so difficult to implement that, but I probably miss something... I wrote a small protoc plugin which inserts self-registration code in each generated *.pb.cc file. This way, I can use the resulting file list to get the descriptor using DescriptorPool::generated_pool()- FindFileByName() but it is totally redundant with generated pool's built-in registration system. What do you think would be the good solution to do that? Thanks, Louis-Marie -- 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.
[protobuf] Re: Efficiently reading/writing multiple messages in C++
On Jun 17, 2010, at 17:05 , Evan Jones wrote: I'm working around this by moving the CodedInputStream inside my loop, which is fine, but seems sub-optimal. At the very least, since I have lots of small messages, this means my ZeroCopyInputStream's methods get called many times. Based on previous mailing list discussions, this is the recommend way to do this. I don't care enough at the moment to test it, but it seems like using a single CodedInputStream for many small messages would be more efficient. Maybe at some point I'll try some benchmarks, but for now I'll ignore this. Evan -- Evan Jones http://evanjones.ca/ -- 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.
