On Apr 23, 1:03 pm, Kannan Goundan kan...@cakoose.com wrote:
The code generated by protoc seems to go to great lengths to make sure
that once a message object is created, it can't be modified. I'm
guessing that this is to avoid cycles in the object graph, so that the
serialization routine
On Apr 18, 4:23 am, TimYang iso1...@gmail.com wrote:
Alkis is quite right, sorry for the typo.
Which JIT were you using, by the way? I found that using the -server
option made the Java ProtoBuf code run more than twice as quickly. Of
course, it could be that the Thrift code would get the same
On Apr 3, 10:40 am, ShirishKul shirish...@gmail.com wrote:
I worked to see the difference between the *XML fast infoset* and the
*Protocol Buffers* (although I'm not aware about what are internal
things happening therein).
I found that for a typical data to be transferred across the wire for
On Mar 27, 1:32 pm, achin...@gmail.com wrote:
If I understand correctly there is no good way to use proto buffers to
stream different types of messages, right? For example if my stream
has a mix of several messages of type m1 and m2, I will have to device
a scheme outside of proto buffers to
On Mar 5, 11:39 pm, Kenton Varda ken...@google.com wrote:
As you know if you've read the docs carefully, when using C++ or Java
protocol buffers, for best performance you need to add a line to your .proto
files:
option optimize_for = SPEED;
snip commentary
I think there are three issues
On Mar 6, 1:24 pm, Justin Azoff justin.az...@gmail.com wrote:
On Mar 6, 1:13 am, Justin Azoff justin.az...@gmail.com wrote: I did a
quick port to python(pasted at the end, hopefully it wont be
garbled)
well, that didn't work.
I threw it up
On Mar 6, 2:23 pm, aepensky apen...@gmail.com wrote:
+1 for making it a compiler command-line option.
Pretty much all other IDLs get this wrong to some degree also.
Having annotations or options in the IDL file is nice, but make sure
they are only helping to define the message and the
On Mar 6, 4:55 pm, aepensky apen...@gmail.com wrote:
Sorry, I realize that wasn't a very clear statement...
What I mean is, if there is an option which does not leave any
fingerprint in either the serialized message or the
FileDescriptorSet, so that you can't tell how the option was set by
On Mar 5, 11:47 am, ijuma isma...@gmail.com wrote:
I haven't optimised with a profiler very recently - I suspect there
are some improvements which could be made by skipping the null
handling when merging/parsing (as it should be unnecessary). I didn't
use any particular options when
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 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#
On Mar 2, 10:14 am, Adewale Oshineye adew...@gmail.com wrote:
This article has some surprising results from it's performance
comparison of Thrift, Protocol Buffers and
JSON:http://bouncybouncy.net/ramblings/posts/thrift_and_protocol_buffers/
More specifically, it's comparing the performance
On Mar 2, 9:35 pm, Marc Gravell marc.grav...@gmail.com wrote:
I'm pretty happy with ongoing general maintenance, but with Jon
working for Google, and it being a closer port of the existing
implementations... I'd realistically expect things may be a little
stacked in favour of that one.
I
13 matches
Mail list logo
