protobuf C++ implementation on "embedded" target

[jonm...@yahoo.com]

Hello,

I am new to the Protocol Buffer community and am evaluating it for a
project I am working on. The project I am working on has a common code
base that runs on both on a Windows PC as well as an embedded target
we have developed running Linux (using Poco library for platform
dependent code). I would like to use the C++ implementation of
protobuf for both targets as they both are written using C++ but am
concerned over what I hear about how big the protobuf library is. The
embedded target in question has an SD card for code space storage
(about 256MB) and 128MB of RAM. Should I immediately rule out the C++
implementation and use the C implementation? Has anyone else used the C
++ implementation for an embedded target that has a generous memory
footprint and CPU speed (~180mHz)?

Thanks,
Jon

[Christopher Smith]

Depending on what else you need resources for and what you are doing, I
think you can work with the C++ library. On my system, libprotobuf.so is
5.1MB WITH DEBUG SYMBOLS (and I did not build it optimized for size). I
tried stripping out the debug symbols, and that shrunk it down to 1.1MB.
As long as you can use the shared library, you pay that penalty only
once. If you need libprotoc.so, that adds another 3.9MB (again, with
debug symbols), and even then you are under 10MB. Assuming your OS is
reasonbly smart about paging in only the needed bits, I think you should
be fine.

--Chris

[Kenton Varda]

The memory footprint of the protobuf library is around a megabyte (stripped).  It sounds like you have enough space for that.  You don't need to worry about speed or runtime memory usage (other than code footprint) -- the implementation is already very heavily optimized on both counts, and that optimization should work equally well on embedded platforms.

That said, we are aware that the footprint is too big.  It was designed for beefy servers, not embedded systems.  The good news is, we're fixing it.  I am currently working with the Google Android developers to produce "lite" versions of both the C++ and Java libraries.  The "lite" libraries will omit support for things like descriptors, reflection, and unknown fields, and thus will be much smaller than the current library.

The "lite" versions will provide a nearly-identical API other than the intentionally missing features.  So, for now, simply make sure that you do not use descriptors or reflection in your code, and you should be able to switch to the "lite" runtime easily once it is available.  I hope to have this in SVN within a few weeks.