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

[Aaron Zeckoski]

Looking over the test I also noticed that nothing in there verifies the
encoding actually worked. This was one issue I ran into a few years ago.
It's not that the JSON or XML would be wrong per se, it's that they were
inconsistent (sometimes the XML used attributes to reflect fields and
sometimes elements, sometimes the class names were stored as part of the
structure, sometimes dates and numbers were flattened into primitives and
other times the classes themselves were encoded, etc.)

The actual Sakai entities are mostly flat structures (not much, if any,
nested data). There are exceptions to this of course but in general the
objects/data are not very complex. Site is probably one of the most complex
(site pages especially). Session is probably one of the simplest with only
a half dozen fields.

I think we will want to do a few things before selecting a possible
replacement.

1) Figure out the memory usage of these encoders, that's perhaps more
important for running at large scale than the encoding time (which aside
from a couple of the encoders are all fairly comparable - within an order
of magnitude from about 1/2 ms to 5 ms).

2) Add in a test which includes a map/collection (along with the random
data pojo test) to make sure it handles that use case (it is pretty common
in providers)

3) Add a test which actually verifies the JSON structure 1 time before
doing the performance test (maybe by stripping all the whitespace and then
comparing the resulting string)

Thoughts?
-AZ


On Thu, Jun 20, 2013 at 4:35 PM, Zach A. Thomas <zach.thomas at gmail.com>wrote:

> 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
>
>
>


-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20130624/58bf44e4/attachment.html