On Mon, Apr 20, 2009 at 8:51 PM, Wink Saville <w...@google.com> wrote:
> I assume the wire format for all variations of protobuf > are compatible of course there are no guarantees. Yes, they are definitely compatible. > > > 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 -~----------~----~----~----~------~----~------~--~---
