In my particular case I'm looking at using protobuf's as an internal
communication scheme between processes, therefore we are both the client and
server. Also, I need to sell this to my colleagues and if it is to large or
is slow it will likely be rejected.

Anyway, your plan looks right on target, what can I do to help?

One other question, is there any reason this can't be applied to Java at the
same time. Android is very Java centric and my first target is for
communication between a Java process and a C/C++ process.

-- Wink

On Tue, Apr 21, 2009 at 1:20 PM, Kenton Varda <ken...@google.com> wrote:

> The protocol buffers implementation was designed to run on beefy server
> machines where we regularly run binaries with hundreds of megs of code and
> don't worry about it that much.
> Optimizing for code size does make the code a lot slower, true, but this is
> compared to an insanely fast base.  It's likely that the speed difference
> won't matter for client-side apps, e.g. on Android.
>
> As for a protobuf-lite, I definitely think this is worthwhile and have been
> thinking about it for awhile now.  I think what we should do is write a new
> superclass of protobuf::Message -- let's call it LiteMessage -- which
> contains only a minimal subset of its methods.  Basically, it would only
> support serialization and parsing.  It would have no descriptors and no
> reflection.
>
> Then, we can add an option which causes the protocol compiler to generate
> only an implementation of LiteMessage -- with only parsing, serialization,
> and field accessors.  Everything else is omitted.  No descriptor, no
> reflection, no UnknownFields, etc.
>
> Then we could factor out a libprotobuf-lite which basically only includes
> LiteMessage, part of wire_format, and the io subdirectory from the protobuf
> code.  And maybe extension_set -- not sure if we want this or not.
>
> On Sun, Apr 19, 2009 at 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
>>
>>
>> >>
>>
>

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