I'm using Sun's java version 1.6.0 on a 64-bit CentOS 5.2
On 64bit Linux, -server is the default option.
On Apr 20, 4:16 am, "Jon Skeet "
wrote:
> On Apr 18, 4:23 am, TimYang wrote:
>
> > Alkis is quite right, sorry for the typo.
>
> Which JIT were you using, by the way? I found that using the
On Apr 18, 4:23 am, TimYang 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 boost...
Jon
--
Alkis is quite right, sorry for the typo.
What I mean my result is
Without optimize_for = SPEED
ProtoBuf Loop : 10,000,000
Get object : 15,130msec
Serdes protobuf: 68,600msec
Objs per second: 145,772
Total bytes: 829,996,683
Thrift Loop: 10,000,000
Get object : 12,651msec
Serde
Are the with/without optimize_for = SPEED flipped? It seems that what you
suggest is that protobuf with optimize_for = SPEED is slower than without.
On Fri, Apr 17, 2009 at 4:45 AM, TimYang wrote:
>
> I've made two similar tests in Java, comparing Thrift and Protocol
> Buffers, and here is the r
I've made two similar tests in Java, comparing Thrift and Protocol
Buffers, and here is the result.
Without optimize_for = SPEED
Thrift Loop: 10,000,000
Get object : 14,394msec
Serdes thrift : 37,671msec
Objs per second: 265,456
Total bytes: 1,130,000,000
ProtoBuf Loop : 10,000,00
FYI, I reran my comparison benchmark using optimize_for = SPEED, and
got the following results:
1) dns.proto with key/value/first/last/type/ttl (mostly strings),
5,000 elements in DnsRecord:
0.019223 seconds to serialize as 658124 bytes with JSON::XS
0.0092 seconds to deserialize 658124 bytes wi
On Mar 4, 10:24 pm, David Anderson wrote:
> I think the major point to take away from the comparison is: use the
> correct tool for your needs. If you need backward/forward
> compatibility, heterogeneous versions of software interacting and some
> structural validation (just structure, not talkin
On Thu, Mar 5, 2009 at 3:20 AM, Alain M. wrote:
>
> Hi,
>
> I was reading this comparison yesterday and was woried about PB
> performance... But today I studied a little more about JSON and I would
> like to share this:
>
> JSON is not at all comparable with ProtBuf, it is much much simpler. It
>
Hi,
I was reading this comparison yesterday and was woried about PB
performance... But today I studied a little more about JSON and I would
like to share this:
JSON is not at all comparable with ProtBuf, it is much much simpler. It
is just a way of putting variables in a pack.
ProtBuf is a m
On Mar 3, 7:37 pm, Dave Bailey 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 found:
>
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 strings
[+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
wrote:
>
> On Monday 02 March 2009, Justin Azoff wrote:
> > I actually posted a follow up:
> >
> http:/
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.
>
On Mar 2, 10:52 am, Stephan Richter 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
> have expected a differen
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 Pyth
On Mar 2, 10:14 am, 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/
More specifically, it's comparing the performance of the Python
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 G
17 matches
Mail list logo
