[Building Sakai] Any Comments on org.codehaus.jackson ??

[Zach A. Thomas]

I didn't update the readme (I should have!) to reflect some of the changes I made.

I reduced the number of items in the test to 1250, because I became impatient. :-)

I didn't change any JAVA_OPTS, I ran it with stock Oracle JDK 1.7.0_25
I have a quad-core iMac from 2011 and 8Gb of RAM.

It would be interesting to see what the memory profiles are in each case. There's probably a way to measure that as well.

I think if we want a more thorough analysis, it would be good to test with the actual Entity classes we're dealing with day to day, but I didn't take it that far. This test isn't perfect, but if nothing else, it test tells us to be very skeptical of XStream!*

Zach



* more like, XStream-ly slow >:-|
On Jun 20, 2013, at 1:29 PM, Aaron Zeckoski <azeckoski at unicon.net> wrote:

> Zach,
> This is very helpful. Thanks for doing this. 
> 
> Those are the numbers for processing 3250 items right?
> 
> Did you have a chance to monitor memory usage during the tests? I don't have a great solution for that but I am curious if the memory profiles are different or generally consistent.
> 
> Also, do you think it would be worth testing another typical Sakai case where the objects being serialized are actually a series of maps with strings, numbers and the like in them? I would be curious to see how that varies from the POJO test (if it all, ideally it would not vary).
> 
> Final question, any JVM settings or just OOTB Java 6?
> 
> -AZ
> 
> 
> 
> On Thu, Jun 20, 2013 at 2:08 PM, Zach A. Thomas <zach.thomas at gmail.com> wrote:
> On Jun 19, 2013, at 6:27 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> 
>> Here's another perf comparison
>> 
>> http://blog.novoj.net/2012/02/05/json-java-parsers-generators-microbenchmark/
>> 
>> Sent from my iPhone
> 
> I forked his benchmark[1], updated all the libraries to their current versions, and modified it so it would work with reflectutils.
> 
> Here's what I came up with. The numbers are time (in milliseconds) spent chewing through roughly 170Mb of JSON. In case the rich text tables don't convey, I also have an image: http://cl.ly/Pm1A
> 
> Serializing
> Jackson
> 685
> Protostuff
> 917
> FastJson
> 952
> Gson
> 1881
> JsonMarshaller
> 2050
> JsonSmart
> 2240
> Staxon-Jackson
> 2680
> FlexJson
> 3798
> Staxon-JsonStream
> 4123
> reflectutils
> 4321
> JsonLib
> 7421
> XStream
> 43211
> 
> Deserializing
> FastJson
> 459
> Protostuff
> 886
> Jackson
> 888
> Gson
> 2170
> reflectutils
> 2708
> JsonMarshaller
> 4047
> FlexJson
> 4462
> Staxon-Jackson
> 8428
> Staxon-JsonStream
> 10817
> XStream
> 22109
> JsonLib
> 71124
> JsonSmart
> error
> 
> Jackson is impressive, but not dominating. The results make me very curious about Protostuff, which I had never heard of before: https://code.google.com/p/protostuff/
> 
> Zach
> 
> [1] https://github.com/zathomas/JavaJsonPerformanceTest
> 
> 
> 
> 
> 
> -- 
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130620/69f7e1ee/attachment.html