If you don't care about the API, why not just use protobuf-c from C++?
If you take away the accessor API, I don't see what C++ gets you.
It's true that the enum descriptor could probably be eliminated... i
was mostly paralleling the c++ api... BUT I like it, cause it could be
useful for language bindings and pretty-printing and parsing,
someday. A patch to not generate them for proto_c-c would be
accepted...
- dave
On Apr 20, 10:29 am, Wink Saville <w...@google.com> wrote:
> 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> 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> 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
-~----------~----~----~----~------~----~------~--~---
