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,
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 lik
Sounds good to me, glad to hear it's not required. One of the things
I'm looking to use protobuf's for is to create a number of small
messages including "enums" and if something isn't being used
it would be nice not to have to carry it around.
-- Wink
On Tue, Apr 21, 2009 at 12:30 PM, wrote:
>
On Mon, Apr 20, 2009 at 8:51 PM, Wink Saville wrote:
> I assume the wire format for all variations of protobuf
> are compatible of course there are no guarantees.
Yes, they are definitely compatible.
>
>
> In my little test program I'm using both and see that
> they are generating the same da
On Apr 21, 11:42 am, Wink Saville wrote:
> 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 thi
See inline.
On Tue, Apr 21, 2009 at 10:11 AM, 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 t
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
I forgot to mention, I stripped all of the files, and in this
case the "embedded" system is a phone (Android) which
is size constrained because of limited flash memory but
does have many executables so shared libraries are the
norm.
On Tue, Apr 21, 2009 at 9:02 AM, Anonymous-ish wrote:
>
> > Bel
> Below is the data I collected. I decided not to do static linking
> as it wouldn't be helpful for a size constrained system.
... curious, but okay. Unnecessary/unresolved symbols and their
associated instructions won't be included in the final resulting
binary, so unless your embedded app does
I assume the wire format for all variations of protobuf
are compatible of course there are no guarantees.
In my little test program I'm using both and see that
they are generating the same data so it is true for
that one data point.
-- Wink
On Mon, Apr 20, 2009 at 6:46 PM, Alain M. wrote:
>
>
Is it possible to use protobuf-c in the embedded side and regular
protbuff in the PC side?
This sound like a win-win option, or am I mistaken???
Thanks in advance for feedback,
Alain
Wink Saville escreveu:
> In the embedded systems they are both important. I potentially see 100's
> of messages
Thanks for the info, I'll create a stripped statically linked binary and
report back.
On Mon, Apr 20, 2009 at 8:49 AM, Observer wrote:
>
> Size in what context? RAM or on disk? Or the amount of memory that
> is required at run time for your application to function?
>
> Create a statically link
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 gen
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
Size in what context? RAM or on disk? Or the amount of memory that
is required at run time for your application to function?
Create a statically linked binary using the same set of tests and post
the results. The size of the .so is a less than perfect test of bloat
or efficiency, but I'd be ha
15 matches
Mail list logo
