I built libprotobuf for the iphone (must be static for app store
apps). It's about 3mb. This results in a significant footprint
increase for applications. Is there any way to reduce this?
Thanks,
Marc
--~--~-~--~~~---~--~~
You received this message because you
I was reading through the code and I'm not sure I understand the
thought behing the ZeroCopyInputStream implementations.
It seems to me that if the underlying data source actually *is* a
stream to begin with, ZeroCopy does not perform any fewer copies;
using the copying adapter, it allocates an
It seems like you should be using
CXXFLAGS=-I/my/install/path/include \
LDFLAGS=-L/my/install/path/lib \
./configure
instead.
--with-libdir is fairly ambiguous with --libdir (a standard automake
option which defines where to put libraries, rather than where to look
for them).
Perhaps
Sorry, our implementation was designed for servers where binary footprint is
not a big deal. Maybe try using protobuf-c?
On Tue, Mar 3, 2009 at 7:09 AM, marc vaill...@cis.jhu.edu wrote:
I built libprotobuf for the iphone (must be static for app store
apps). It's about 3mb. This results in
Justin,
Thanks for writing this up; I think it's a nice real world example.
I ran an equivalent test (using your same .proto files) in Perl to
compare JSON::XS, protobuf-perlxs, and Storable. I did this on an
x86_64 quad-core Xeon (2.5 GHz) and found:
1) Your original dns.proto (with
We use a --with-protobuf option in protobuf-perlxs.
http://code.google.com/p/protobuf-perlxs/source/browse/trunk/configure.ac
I actually copy-pasted the configure.ac part that implements --with-
protobuf into the protobuf-c configure.ac so I could build protobuf-c
in my environment recently.
Thanks for the quick response...
So, to do an RPC implementation over a stream channel (e.g. TCP),
where the message length is being sent in advance of the message body,
the fastest way would still be
(1) allocate bytes[length]
(2) stream.read(bytes, length)
(3) message.ParseFromArray(bytes,
On Tue, Mar 3, 2009 at 12:20 PM, aepensky apen...@gmail.com wrote:
Thanks for the quick response...
So, to do an RPC implementation over a stream channel (e.g. TCP),
where the message length is being sent in advance of the message body,
the fastest way would still be
(1) allocate
[+dave]
On Tue, Mar 3, 2009 at 11:33 AM, marc vaill...@cis.jhu.edu wrote:
On Mar 3, 1:42 pm, Kenton Varda ken...@google.com wrote:
Sorry, our implementation was designed for servers where binary footprint
is
not a big deal. Maybe try using protobuf-c?
Ok thanks. Getting the
On Mar 3, 7:37 pm, Dave Bailey d...@daveb.net wrote:
Thanks for writing this up; I think it's a nice real world example.
I ran an equivalent test (using your same .proto files) in Perl to
compare JSON::XS, protobuf-perlxs, and Storable. I did this on an
x86_64 quad-core Xeon (2.5 GHz) and
On Mon, Mar 2, 2009 at 11:19 PM, Jon Skeet sk...@pobox.com
sk...@pobox.com wrote:
There's one major blocker at the moment though: all my copies of the
Google test .proto files are decorated with the C# options. *At the
moment* that means the Java and C++ code would have to build the C#
On Mar 3, 11:06 pm, Kenton Varda ken...@google.com wrote:
sk...@pobox.com wrote:
There's one major blocker at the moment though: all my copies of the
Google test .proto files are decorated with the C# options. *At the
moment* that means the Java and C++ code would have to build the C#
I think the long-term solution for options is to find some good syntax for
specifying options on the command-line so that they don't all have to be in
the .proto file itself. There are lots of use cases for this sort of thing.
On Tue, Mar 3, 2009 at 3:10 PM, Jon Skeet sk...@pobox.com
Without the actual config.log it's hard to tell what's going on. You
may send it to me privately if you want.
If you have a working endian.h or mach/endian.h, we shouldn't need
to run a test program. but i have never written an iphone app, so i
have really no idea if they have such a header.
14 matches
Mail list logo
