See inline.
On Tue, Apr 21, 2009 at 10:11 AM, <lahike...@gmail.com> wrote:
>
> 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.
I will probably look at doing just that if there is no interest in a
protobuf-lite.
>
>
> 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...
Maybe I'll do this too:) But could you give me some insight on how you
use the enum descriptor, maybe I'm missing something. All I want to
do is have a "structure" defined and be able to serialize and deserialize
that structure. That's what I think the minimum protobuf-lite is, but
again, maybe I'm totally missing something.
-- Wink
>
> - 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
-~----------~----~----~----~------~----~------~--~---
