On Jul 18, 2012, at 16:14 , Jeremy wrote:
I understand, but if one wants to keep a large persistent message allocated
and walk over it frequently, there is a price to pay on cache misses that can
be significant.
I guess you are wishing that the memory layout was completely contiguous? Eg.
On Jul 17, 2012, at 2:33 , Jeremy Swigart wrote:
Is there a way to tell the proto compiler to generate message definitions for
which the message fields are statically defined rather than each individual
field allocated with dynamic memory? Obviously the repeater fields couldn't
be fully
On Jul 14, 2012, at 10:55 , jrf wrote:
Is there a reason that a python equivalent of CodedInputStream is not part of
protobuf?
I seem to recall that the answer is basically yeah, it probably should be but
no one really works on this stuff any more.
You can dig around in the
On Jul 16, 2012, at 14:43 , jrf wrote:
Is that because protobufs is done or not being further developed?
You would need to get someone from Google to answer. The impression I get is
that the open source release is, at the very least, in maintenance mode where
they occasionally fix bugs etc.
On Jun 26, 2012, at 11:08 , d34th4ck3r wrote:
What is it that I am doing wrong?
Protocol buffers are a *binary* format. Those funny characters at the end of
the string are probably part of the message, and you should leave them there.
You also should not be passing them around as strings. They
On Jun 18, 2012, at 22:49 , Justin Muncaster wrote:
I'm currently changing our build system to be cmake based and I'm again
finding myself fighting with the build system to get the .proto to be
automatically generated in a way where they build correctly.
What specific problems are you
On May 29, 2012, at 23:26 , msrobo wrote:
According to the documentation, it's recommended that the message size
be = 1 Megabyte. I've searched around for the reason for this
recommendation, but I can't seem to find anything. Based on some basic
benchmarking serializing/unserializing messages
On May 16, 2012, at 5:02 , secondsquare wrote:
After generating cpp files, the member becomes msgsize.
Big ‘S’ is changed to little 's'.
This is by design. Protocol buffers follows Google's style guide where C++
names_use_underscores while Java names useCamelCase. Protobuf will generate the
On May 9, 2012, at 15:26 , Jeremy Stribling wrote:
* There are two nodes, 1 and 2, running version A of the software.
* They exchange messages containing protobuf P, which contains a string field
F.
* We write a new version B of the software, which changes field F to an
integer as an
On May 8, 2012, at 21:26 , Jeremy Stribling wrote:
Thanks for the response. As you say, this solution is painful because you
can't enable the optimization until the old version of the program is
completely deprecated. This is somewhat simple in the case that you yourself
are deploying the
On Mar 31, 2012, at 4:31 , Dhanaraj G wrote:
I have gone through he following link..
http://code.google.com/p/metasyntactic/wiki/ProtocolBuffers
There is no official support but I've used the following distribution with
success, with the latest protoc (I'm pretty sure):
On Mar 26, 2012, at 21:49 , Galileo Sanchez wrote:
Thanks man... It worked great! I guess I should read the documentation a
little more xP.
Sadly these functions aren't actually documented. The Python API doesn't expose
these routines for some reason I don't understand / remember. Glad it
On Mar 23, 2012, at 9:07 , Simon wrote:
I have an annoying problem with some accent.
I build my proto-object, no problem, and when i want to read it the
browser, using .toString function, i have \303\240 instead of à,
\303\250 instead of è, etc…
What do you mean i want to read it the browser
On Mar 25, 2012, at 18:09 , Galileo Sanchez wrote:
else
if (Should I write the size as a raw bit string?)
thenHow do I do that?
You need to use something like the following. Not 100% sure it works but it
should be close? Hope this helps,
Evan
# Output a message to
On Mar 20, 2012, at 16:12 , Mick wrote:
These objects are going to be accessible to multiple users, who's accessor
programs may be on different release cycles. I have been looking into
protocol buffers as a way of managing dataloss/corruption between versions.
Has anyone used protocol
On Mar 8, 2012, at 2:30 , waynix wrote:
Since this is so common an issue and the suggested solution is almost
de facto standard, (saw this after my initial post:
http://code.google.com/apis/protocolbuffers/docs/techniques.html), it
begs the question of why not build it into protobuf proper.
On Feb 27, 2012, at 17:27 , waynix wrote:
1. Is this still the way to do it? Seems quite cumbersome (to lazy me ;-).
Is there a wrapper built in to do this?
Yes. Sadly there is no wrapper included in the library.
2. If I understand Jason's suggestion riht, the length is really not
part
On Feb 20, 2012, at 8:25 , Frank Durden wrote:
I'm sorry if this is explained somewhere, I couldn't find an answer.
Are protobuf messages (in Java) thread safe for concurrent reads. I
guess they're immutable in the sense that you can't modify them after
they're built, but can a message object
On Feb 20, 2012, at 16:20 , Christopher Smith wrote:
Message objects *don't* have mutators and are conceptually a copy of the
relevant builder object.
Having attempted to refresh my knowledge of the Java Memory Model, I think
there is a subtle difference between an object that has all final
On Feb 6, 2012, at 21:54 , Robby Zinchak wrote:
It turned out to be an uninitialized boolean. Properly setting the value in
question seems to allow things to proceed normally.
Ah! Interesting. So one of your .set_* properties is a boolean, and one of them
was uninitialized? That would do it.
This is weird. I don't see any clear potential cause, so I have a few questions:
HTMud::EnvAdd item;
item.set_id(ID);
item.set_idtype(typeID);
item.set_x(X);
item.set_y(Y);
item.set_z(Z);
item.set_lockdown(lockdown);
item.set_mapid(map);
item.set_tilesetno(tilesetNo);
On May 16, 2011, at 9:45 , Nigel Pickard wrote:
I have actually got the code working, but it involves creating a new
output stream everytime I write to it (surely got to be wasteful and
not the right way?).
Definitely not needed, and it will be more efficient if you can re-use
a single
On May 13, 2011, at 10:12 , Nigel Pickard wrote:
libprotobuf FATAL google/protobuf/io/zero_copy_stream_impl_lite.cc:
346] CHECK failed: (buffer_used_) == (buffer_size_): BackUp() can
only be called after Next().
Off the top of my head, I *believe* this is happening because the
On Apr 1, 2011, at 6:54 , AdrianPilko wrote:
What is the [best] way to determine the on the wire size?
You probably want msg.ByteSize() in C++, msg.getSerializedSize() in
Java.
Evan
--
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
On Mar 6, 2011, at 18:45 , ksamdev wrote:
I think I found the source of the problem. The problem is that
CodedInputStream has internal counter of how many bytes are read so
far with the same object.
Ah, right. With the C++ API, the intention is that you will not reuse
the
On Mar 7, 2011, at 13:03 , ksamdev wrote:
Hmm, thanks for the advice. It may work fine. Nevertheless, I have
to skip previously read messages in this case every time
CodedInputStream is read.
Not true: Creating a CodedInputStream does not change the position in
the underlying stream. Your
On Mar 4, 2011, at 7:15 , Aditya Narayan wrote:
I have created .proto files and compiled them to get the generated
classes. Also I can build the message objects using the setters
finally build() method. But to store it to database, I need
serialized data as byte[] or byte buffers. How do I
On Mar 3, 2011, at 15:53 , Linus wrote:
I am wondering if there are any examples of chunking large PB messages
(about 1MB) into smaller chunks, to transmit over the wire.
This is going to be pretty application specific. Typically it involves
taking one message with a huge repeated field and
On Mar 4, 2011, at 11:11 , Aditya Narayan wrote:
Exception in thread main java.lang.RuntimeException:
Uncompilable source code
This error means there is a build problem in your Eclipse project. You
are trying to call some code that is not building compiled correctly.
Fix your
On 03/02/2011 10:04 AM, ZHOU Xiaobo wrote:
required string Content = 3;
WARNING: You should be using type bytes here, not type string. This
doesn't matter for C++, but matters for other languages which will
assume strings contain UTF-8 data.
Evan
--
http://evanjones.ca/
--
You
On Feb 28, 2011, at 11:46 , footloose wrote:
The tutorials talk only about marshalling and un marshalling the data
structures. Do the sockets have to be written manually?
Yes. The protocol buffer library from Google does not include an RPC
implementation. There are a bunch of third-party
On Feb 21, 2011, at 3:06 , Amit Pandey wrote:
Did anyone get the chance to look into it.
If you want to use the RPC system, you need to provide your own
implementation, or maybe use an existing one, such as:
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns#RPC_Implementations
If
I read this proposal somewhat carefully, and thought about it for a
couple days. I think something like this might solve the problem that
many people have with streams of messages. However, I was wondering a
couple things about the design:
* It seems to me that this will solve the problem
On Feb 8, 2011, at 13:34 , Kenton Varda wrote:
I handle user messages by passing them as bytes, embedded in my
own outer message.
This is what I do as well, as does protobuf-socket-rpc:
http://code.google.com/p/protobuf-socket-rpc/source/browse/trunk/proto/rpc.proto
I guess I was thinking
On Jan 26, 2011, at 3:43 , Hitesh Jethwani wrote:
Can we encode the protobuf data in ISO-8859-1 from the server end
itself?
Yes. In this case, you need to use the protocol buffer bytes type
instead of the protocol buffer string type, since you want to
exchange ISO-8859-1 bytes from
On Jan 25, 2011, at 15:27 , Hitesh Jethwani wrote:
As may be evident from above I am naive at Java and Protobuf. Any
help on this is appreciated.
The Java protocol buffer API encodes strings as UTF-8. Since C++ has
no unicode support, what you get on the other end is the raw UTF-8
message in the stream?. See:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
the archives of this group also contain many discussions on this
subject.
Evan Jones
--
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
of a pain. Good luck,
Evan Jones
--
http://evanjones.ca/
--
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
work, but it works.
Evan
--
Evan Jones
http://evanjones.ca/
--
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
with the
framework you are using, but this should be feasible. Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
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
/protorpc/ProtoConnection.java#l40
Evan
--
Evan Jones
http://evanjones.ca/
--
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
) method of this class, so it is
actually pretty straightforward. There might be a better way but it
works for me. Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group
are really sending / writing a large number of
messages, you want to read something like:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming
Good luck,
Evan Jones
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google
to worry about the ByteBuffer being accidentally
changed, etc). The latest version of Protocol Buffers in Subversion
has ByteString.copyFrom(ByteBuffer) which will do what you want
efficiently.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed
he was interested in the same problem.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr
();
}
You can get defaultInstance from
ConcreteMessageType.getDefaultInstance();
You may want to create a tiny InputStream wrapper around ByteBuffer to
avoid an extra copy, or if you know it is a heap byte buffer, use the
array mergeFrom().
Hope that helps,
Evan
--
Evan Jones
http
, although I don't think I ever considered this particular
version. However, I think this can be made thread-safe, even without
volatile (although I only understand the JMM enough to be dangerous).
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed
already have both byte[] and
String fields for each string due to an encoding improvement I
contributed, so this should be nearly a pure win.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post
a length. See:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming
Or search the group archives for threads such as:
http://groups.google.com/group/protobuf/browse_thread/thread/3af587ab16132a3f
Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received
are using UDP, it will end up not working as soon as you
have a message which is bigger than either your buffer, or the maximum
UDP packet size, whichever comes first.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
these objects. See:
http://code.google.com/apis/protocolbuffers/docs/javatutorial.html
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com
. This is typically
easier since CopyingInputStreamAdaptor then implements the appropriate
buffering logic.
See:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.io.zero_copy_stream_impl_lite.html#CopyingInputStreamAdaptor
Good luck,
Evan
--
Evan Jones
http
only need to choose between a limited set of
types, you may want a union type or extensions instead:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
http://code.google.com/apis/protocolbuffers/docs/proto.html#extensions
Evan
--
Evan Jones
http://evanjones.ca/
--
You
://people.csail.mit.edu/evanj/hg/index.cgi/javatxn/file/tip/src/ca/evanjones/protorpc/ServiceRegistry.java
http://people.csail.mit.edu/evanj/hg/index.cgi/javatxn/file/tip/src/ca/evanjones/protorpc/ProtoMethodInvoker.java
Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because
On Oct 25, 2010, at 21:45 , Paul wrote:
optional string meas_rec_str = 2;
Change this to:
optional bytes meas_rec_str = 2;
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group
are serialized differently.
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email
http://www.javapractices.com/topic/TopicAction.do?Id=29)
That said, I think you *might* be able to hack something like this
using the Builder object. I would be interested to know if you try
this, and if it has any performance benefits.
Evan
--
Evan Jones
http://evanjones.ca/
--
You
as well.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr
for many conversations about this. Hope this helps,
Evan
http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group
using the protobuf API: it handles any required
byte swapping for you.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from
if
that is getting called multiple times?
This FileDescriptorTable object is used internally by the protobuf
library and I don't really understand it. I'm hoping someone who might
understand this code might be able to suggest where this double free
could be coming from.
Evan
--
Evan
:
codedOutput.WriteVarint32(msg.ByteSize());
msg.SerializeToCodedStream(codedOutput);
codedOutput.flush();
...
Hope this helps,
Evan
(as an aside: the C++ API really should have an equivalent to
writeDelimitedTo and parseDelimited on the Java side).
--
Evan Jones
http://evanjones.ca/
--
You received
) are coming out the other end and
getting passed into parseDelimited. It might be helpful if you sent a
snippet of code where you are sending and receiving the messages, but
I can't think of anything off the top of my head.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message
. The FileDescriptorTables are static
objects of sorts, I think. Are you calling ShutdownProtobufLibrary()
somewhere? Maybe more than once? Memory leaks *will* be reported by
valgrind if you don't call ShutdownProtobufLibrary(), but I don't know
what could cause a double free.
Evan
--
Evan Jones
rather than a struct or container type. There are some
languages which do not support more complex key types in their
native map types. In addition the JSON protocol only supports key
types that are base types.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you
I never call the CodedInputStream routines unless I know
there is sufficient data. This may not be ideal for your application,
so your milage may vary.
Good luck,
Evan Jones
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
it is convenient.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr
is in the google::protobuf::internal namespace, rather than in
google::protobuf?
Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com
service. Were I to start it today,
I would use the code generator, since there are a few small things in
the automatically generated RPC interface that I would like to change.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
)
http://code.google.com/apis/protocolbuffers/docs/reference/java/com/google/protobuf/MessageLite.Builder.html#mergeDelimitedFrom(java.io.InputStream)
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group
that improves Java
message *encoding* performance, by optimizing string encoding. It is
available at the following URL. Unfortunately, there is no similar
approach to improving the decoding performance.
http://codereview.appspot.com/949044/
Evan
--
Evan Jones
http://evanjones.ca/
--
You
#union
Two RPCs:
service Service {
rpc sendObject1(Object1) returns (Result1);
rpc sendObject2(Object2) returns (Result2);
}
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post
message. However, I
suspect that isn't really a big overhead. You can also use
YourProtocolMessage.getDefaultInstance() to avoid creating a message.
Hope this helps,
Evan Jones
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
and fill in the length
field. This would be an incompatible change to the serialization
format, however.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto
, or MessageLite::
ParseFromBoundedZeroCopyStream).
Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send
On Aug 4, 2010, at 9:50 , mark.t.macdon...@googlemail.com wrote:
Is there a way I can do this without creating a Pixel pointer?
Something like this (which doesn't compile):
Try fractal.mutable_pixel(0)-set_*
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received
/browse_thread/thread/a4bc2a3788d356f6
Read that thread for details, but the summary is: patches welcomed.
CodedInputStream is pretty lightweight though, so creating and
destroying one per message should be pretty efficient.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message
is what that method does under the covers (I think).
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send
you have memory
corruption somewhere? Try using valgrind if you might have memory
corruption. Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto
but the 'EnhancedRpcController' then
becomes a pervasive cast as well as a RPC implementation lockin
This is probably the worst part of the built-in service API, in my
opinion. I end up with casts related to controllers in lots of places.
Its ugly, but I don't see any good way to fix it.
Evan
--
Evan
(effectively). The second has to do
some sort of table lookup. You want to use the first form if you care
about performance.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email
be generated. Note that the .proto you sent
doesn't have RETRACTED defined, so maybe that is your problem?
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto
/Descriptors.Descriptor.html#getFullName()
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf
luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
/ CodedOutputStream is probably
helpful.
Also: did you look at the third party libraries? Many programming
languages have implementations you could try using:
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you
);
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more
(success);
This works for me.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf
as they are written out, rather than
needing to serialize the entire thing to a byte[] array, then compress
it. This could be better, but as always you'll have to measure it.
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed
message.writeTo(servletOutputStream)
If you are writing multiple messages, you'll probably want to
explicitly create a single CodedOutputStream to write all of them.
If you experiment with this and find something different, I would be
interested to know.
Evan
--
Evan Jones
http://evanjones.ca
. This is trickier than re-using a single
CodedOutputStream. If you are interested, I can send the details about
what I have used. Although to be honest: I haven't tested it carefully
to see if this is *actually* faster than doing the simple thing such as
.parseFrom() and friends.
Evan
--
Evan Jones
http
be
opposed to putting some effort into including it in protobuf, or in a
protobuf-utils type project.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto
On Jun 17, 2010, at 17:05 , Evan Jones wrote:
I'm working around this by moving the CodedInputStream inside my
loop, which is fine, but seems sub-optimal. At the very least, since
I have lots of small messages, this means my ZeroCopyInputStream's
methods get called many times.
Based
in 32.337s;
15.353779MB/s
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr
call .resetSizeCounter() occasionally, I think it should work just
fine. I'm certainly using a single Java CodedInputStream per long
lived connection without any trouble. Unclear if I've sent 2GB of
data over a single connection though.
Evan
--
Evan Jones
http://evanjones.ca/
--
You
?
No, this should work just fine. On the input size, you'll need to call
CodedInputStream.resetSizeCounter() after each message, otherwise
you'll run into the size limit.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers
this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
a ThreadLocal?
From memory, the ThreadLocal appears to be very cheap, and not make
much performance difference, but I should double check this as well.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group
others
are interested.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr
there we should be able to decode directly from the input buffer,
saving a copy and an allocation of a temporary byte[] array. Unclear
if this will actually be significantly faster, but it might be
slightly faster.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message
1 - 100 of 131 matches
Mail list logo
