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/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the
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 Monday 02 March 2009, Adewale Oshineye 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/
The outcome looks about right. In the latest version of
On Mar 2, 10:52 am, Stephan Richter stephan.rich...@gmail.com wrote:
The outcome looks about right. In the latest version of Python, even
simplejson has C extensions. A one order of magnitude difference between a
pure Python versus C implementation is about right, if not too small. I would
I'm interested in your work, Josh. But I'm having trouble
understanding what your goal is. I.e. what is the essence of protobufs
that you are trying to distill? And how would you differentiate your
work from Dave's protobuf-c project? And is your implementation going
to be entirely in C?
Tim
On
I would be using pb message structs not only as a messages between
objects, but also for data storage within active objects in an
embedded c++ app. This makes the most sense, in terms of minimizing
copies. I would like to be able to extend whatever framework we choose
to be able to automate
On Monday 02 March 2009, Justin Azoff wrote:
I actually posted a follow up:
http://bouncybouncy.net/ramblings/posts/more_on_json_vs_thrift_and_protocol
_buffers/ It turned out I didn't have the simplejson C extension
installed... With that installed the speed difference was much greater.
The
On Mon, Mar 2, 2009 at 3:43 AM, Jon Skeet sk...@pobox.com wrote:
I've ported the code to Java, but haven't sent it to Kenton yet. I don't
know exactly where we'd want to put it in the main distribution. Kenton, how
do you want to proceed with this?
A top-level benchmark directory seems like
[+petar]
Petar, want to share what you have so far on the C-extension stuff? Maybe
someone with more time available would like to help with it.
On Mon, Mar 2, 2009 at 10:04 AM, Stephan Richter
stephan.rich...@gmail.comwrote:
On Monday 02 March 2009, Justin Azoff wrote:
I actually posted a
I don't think that's something we want to do in general, because storing the
callbacks would make the message objects much bigger, and checking for their
presence would add branches in all the setter methods, both of which would
harm performance.
That said, you could write a custom protoc which
It seems strange to me that C# did not merit first class support. I am
sure that fact reflects the non-usage of .Net internally at google,
but once these three projects have put the effort into doing that
work, why not incorporate the best of those into this, the parent
project? I find the CLR
I'm happy to add C# (or any other popular language) to the main distribution
if two conditions are met:
1) The implementation is relatively stable and proven, so that we don't find
ourselves needing to do more frequent releases just for its sake, and so
that we don't find ourselves needing to
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.
Even if that comes to pass, I'll still maintain protobuf-net anyway,
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
14 matches
Mail list logo
