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
-~----------~----~----~----~------~----~------~--~---

Reply via email to