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
-~----------~----~----~----~------~----~------~--~---
test1.tgz
Description: GNU Zip compressed data
