I assume the wire format for all variations of protobuf are compatible of course there are no guarantees.
In my little test program I'm using both and see that they are generating the same data so it is true for that one data point. -- Wink On Mon, Apr 20, 2009 at 6:46 PM, Alain M. <ala...@pobox.com> wrote: > > Is it possible to use protobuf-c in the embedded side and regular > protbuff in the PC side? > > This sound like a win-win option, or am I mistaken??? > > Thanks in advance for feedback, > Alain > > Wink Saville escreveu: > > In the embedded systems they are both important. I potentially see 100's > > of messages being defined so generated code size could be a problem. > > Also, as I have no existing code right now an incompatible version isn't > > a problem for me. > > > > One thing that does surprise me is the cost of an enum in the generated > > code. My expectation is that there should be zero runtime cost. But is > > appears there is some need for a data structure to describe them, could > > you educate me why they need the extra infrastructure? > > > > -- Wink > > > > On Mon, Apr 20, 2009 at 10:15 AM, <lahike...@gmail.com > > <mailto:lahike...@gmail.com>> wrote: > > > > > > Frankly I'm surprised so many people care about the generated code > > size - I'm generally much more interested in speed. > > For example, I suspect your C unpack() could be optimized quite a bit > > by using a custom allocator. Another example: probably the only > > change I'm likely to make to protobuf-c in the forseeable future is a > > rewrite of "pack()" to optimize packing of submessages... well, and > > i'll probably need to follow protobuf if it implements packed > repeated > > fields (another great optimization). > > > > If I were designing a C++ protobuf, I'd probably use the strategy I > > used for protobuf-c: make the reflection data so efficient and easy > > that you can optimize the hell out of the reflection-based api, > > thereby: > > - only needs one copy of the pack/unpack code, in the core library > > - eliminate the difference between optimize for speed or size -- it's > > really possible to do both! > > - minimizes the generated code to be practically nothing but > > introspection data > > - in theory, one could bind the C objects could to other languages > > using the reflection api > > > > Unfortunately, some amount of bloat is inherent in the C++ tradition > > of using accessor methods for the various members. More bloat from > > std::string. etc. So I'm not sure you "lite" you can get w/o making > > a completely incompatible version. > > > > - dave > > > > On Apr 19, 4:45 pm, Wink Saville <w...@google.com > > <mailto:w...@google.com>> wrote: > > > I've been looking at protobuf and I'm somewhat disappointed by > > the size of > > > the library on X86_64 and the size of the generated code for a > simple > > > message: > > > > > > $ size libprotobuf.so > > > text data bss dec hex filename > > > 1008339 21344 1128 1030811 fba9b > libprotobuf.so > > > > > > The flags for gcc I used for my simple test program was: > > > > > > CFLAGS := -Wall -g -DGOOGLE_NO_RTTI -o2 > > > > > > The simple protobuf message was: > > > > > > $ cat test1.proto > > > syntax = "proto2"; > > > option optimize_for = SPEED; > > > > > > package protobuf_tests; > > > > > > message test1 { > > > required int32 v = 1; > > > optional int32 o = 2; > > > repeated string s = 3; > > > > > > } > > > > > > Size when optimized for speed: > > > > > > text data bss dec hex filename > > > 15851 8 33 15892 3e14 test1.pb.o > > > > > > Size when not optimized for speed:: > > > > > > text data bss dec hex filename > > > 6852 8 33 6893 1aed test1.pb.o > > > > > > As would be expected the performance hit was pretty large, > > optimized for > > > speed: > > > > > > test1_cpp serialze Done total=0.656162secs 1000000 loops > 656ns/loop > > > test1_cpp deserialize Done total=0.434740 1000000 loops 434ns/loop > > > > > > without optimized for speed: > > > > > > test1_cpp serialze Done total=1.994011secs 1000000 loops > 1994ns/loop > > > test1_cpp deserialize Done total=1.609001 1000000 loops > 1609ns/loop > > > > > > The two loops are below: > > > > > > nsecs_t start = system_time_ns(); > > > for (int i=loops; i != 0; i--) { > > > t.SerializeToString(&data); > > > } > > > nsecs_t stop = system_time_ns(); > > > > > > start = system_time_ns(); > > > for (int i=loops; i != 0; i--) { > > > x.ParseFromString(data); > > > } > > > stop = system_time_ns(); > > > > > > Given the above, I thought I'd try protobuf-c which appears to > > ignore the > > > speed option, > > > it is quite a bit smaller and somewhat faster on this simple > message: > > > > > > text data bss dec hex filename > > > 1370 56 0 1426 592 > test1.pb-c.o > > > 51751 1320 16 53087 cf5f > > libprotobuf-c.so > > > > > > test1_c serialze Done total=0.182868secs 1000000 loops 182ns/loop > > > test1_c deserialize Done total=0.420284 1000000 loops 420ns/loop > > > > > > The loops for protobuf-c are: > > > > > > nsecs_t start = system_time_ns(); > > > for (int i=loops; i != 0; i--) { > > > size = protobuf_tests__test1__get_packed_size(&t); > > > protobuf_tests__test1__pack(&t, data); > > > } > > > nsecs_t stop = system_time_ns(); > > > > > > start = system_time_ns(); > > > for (int i=loops; i != 0; i--) { > > > _ProtobufTests__Test1 *x = > > protobuf_tests__test1__unpack(NULL, size, > > > data); > > > protobuf_tests__test1__free_unpacked(x, NULL); > > > } > > > stop = system_time_ns(); > > > > > > So protobuf library is about 19x larger (1,000,000/52,000) and > > the code is > > > about 11x larger (16,000/1,400) > > > when optimized for speed and about 5x larger (6,00/1,400) when > > not optimized > > > for speed. I could be making > > > an inappropriate comparison and the protobuf-c is certainly not > > as mature > > > but it does look encouraging. > > > > > > This may not be news to anyone, but the large difference makes me > > wonder if > > > it would be worth > > > while to create protobuf-lite. What do people feel the minimum > > feature set > > > that would be needed > > > for protobuf-lite? Does anyone else feel a lite version would be > > desirable? > > > > > > Other ideas comments? > > > > > > -- Wink > > > > > > test1.tgz > > > 2KViewDownload > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
