Comments on: Json serialization/deserialization faster than protocol buffers?

By: Falconi

Falconi — Sun, 23 Aug 2009 03:25:42 +0000

Hi, this is really nice post i like it so much
thank very much

By: Cowtowncoder

Cowtowncoder — Thu, 02 Apr 2009 18:50:54 +0000

ByteArrayOutputStream.toByteArray() also does make a virgin copy. So I think it is doing about the same as what PB does in the end.
But if BAOS is re-created each time, it is doing allocations twice. This may be exactly what PB does too.

In the end though I agree in that it doesn’t matter too much, either way, as long as BAOS is not created way too small (which it isn’t with current test code).

By: Eishay

Eishay — Wed, 01 Apr 2009 05:07:58 +0000

I saw it too, but it is not the same thing as reusing an existing memory block over and over (as you do in rest) instead of allocating new memory each time and throwing it to the gc (as protobuf toByteArray does). Not arguing about the efficiencies of the modern gc with young objects in eden etc, just saying it is not the same cpu/memory usage profile.

By: Cowtowncoder

Cowtowncoder — Wed, 01 Apr 2009 01:28:06 +0000

Eishay: I wish I had seen comments earlier.
Please note that ByteArrayOutputStream.reset() is practically free: all it does it does it set pointer variable to 0. This is much cheaper than allocating a new stream.

I know that many other JDK classes do some cleanup, like ArrayList clearing up entries when size is set to 0. But BOS doesn’t (I checked JDK sources to ensure that).

Of course, it probably does not make that much difference like you say, so maybe it’s all irrelevant. :-)

By: Ismael Juma

Ismael Juma — Fri, 27 Mar 2009 09:25:54 +0000

I replied in Eishay's post.

By: Eishay Smith

Eishay Smith — Thu, 26 Mar 2009 23:30:25 +0000

I changed the benchmarking to have the serializer create its own stream if it needs to. It doesn’t make mush of a difference. The other thing I did was to create a new object to serialize every time (not reuse the same one). The latter dramatically reduce the performance of protobuf serialization. I’ll write about it more once I’ll have time. The code it checked in, if you have a chance please let me know if you think its fair for all serializers.

By: Ismael Juma

Ismael Juma — Thu, 26 Mar 2009 19:42:41 +0000

Regarding the ByteArrayOutputStream.reset, I am not convinced that the latest change not to include it in the final time is correct.

In normal usage, you’d have to reset it or create one, right? The fact that protocol buffers does this efficiently internally should be rewarded (or a similar approach should be used in the various serializers).

Ismael

By: Ismael Juma

Ismael Juma — Thu, 26 Mar 2009 19:39:42 +0000

Hi Eishay,

Interesting, I updated from SVN, but I get different results:

Object create, Serialization, Deserialization
protobuf 302.05880, 209.97715, 244.49875
json(jackson) 141.42370, 225.06970, 344.70990

What JDK are you using? Also, are the results repeatable?

Ismael

By: Eishay

Eishay — Thu, 26 Mar 2009 07:42:42 +0000

Hi,

I added the fix, but to be fair to the other serializors I also removed the ByteArrayOutputStream reset out of the time measurements. Here is a snippet from the results (didn’t publish them yet):
Object create,Serialization,Deserialization
protobuf 492.90000,325.60000,444.75000
json (jackson) 289.05000,324.55000,429.00000

By: Eishay

Eishay — Thu, 26 Mar 2009 03:05:09 +0000

I was about to commit the fix when realizing that it may not by so fair to the other serializers. There is a hidden cost in the loop where we do ByteArrayOutputStream::reset(), I’ll try to take it out of the equation.

By: Ismael Juma

Ismael Juma — Thu, 26 Mar 2009 00:07:00 +0000

Hi Cowtowncoder,

Yes, I try to be a good open-source citizen. :) I had filed an issue with a patch earlier today:

http://code.google.com/p/thrift-protobuf-compare/issues/detail?id=2

Best,
Ismael

By: Cowtowncoder

Cowtowncoder — Wed, 25 Mar 2009 23:58:18 +0000

Hi there! You might want to contribute the PB patch to the benchmark project — I think they’d be happy to take it. That’s how other codecs have been improved.