Remove JSON-LIB from codebase?

[Louis Ryan <lr...@google.com>]

We currently have two JSON bindings in the Java Shindig codebase. The
JSON-lib one isnt used (?) and adds a significant amount of code. I believe
that it is faster than the JSON.org implementation but I dont know if we
have a critical performance need here yet. Id be in favor of removing it, we
can always add back later. Thoughts?

Re: Remove JSON-LIB from codebase?

[Adam Winer <aw...@google.com>]

That sounds reasonable - but getting down to one JSON library first
seems like a good precursor to hiding JSON altogether, right?

On Mon, Feb 9, 2009 at 5:27 PM, Kevin Brown <et...@google.com> wrote:
> I think if we move BeanJsonConverter into common and rename it (since it
> handles things that aren't beans), we can hide all JSON serialization and
> parsing logic behind this and JsonSerializer. Code will then never have to
> worry about how to deal with JSON, it can deal with java primitives,
> collections, and beans.
>
> On Mon, Feb 9, 2009 at 5:18 PM, Louis Ryan <lr...@google.com> wrote:
>
>> We currently have two JSON bindings in the Java Shindig codebase. The
>> JSON-lib one isnt used (?) and adds a significant amount of code. I believe
>> that it is faster than the JSON.org implementation but I dont know if we
>> have a critical performance need here yet. Id be in favor of removing it,
>> we
>> can always add back later. Thoughts?
>>
>

Re: Remove JSON-LIB from codebase?

[Kevin Brown <et...@google.com>]

I think if we move BeanJsonConverter into common and rename it (since it
handles things that aren't beans), we can hide all JSON serialization and
parsing logic behind this and JsonSerializer. Code will then never have to
worry about how to deal with JSON, it can deal with java primitives,
collections, and beans.

On Mon, Feb 9, 2009 at 5:18 PM, Louis Ryan <lr...@google.com> wrote:

> We currently have two JSON bindings in the Java Shindig codebase. The
> JSON-lib one isnt used (?) and adds a significant amount of code. I believe
> that it is faster than the JSON.org implementation but I dont know if we
> have a critical performance need here yet. Id be in favor of removing it,
> we
> can always add back later. Thoughts?
>

Re: Remove JSON-LIB from codebase?

[Ian Boston <ie...@tfd.co.uk>]

That may not be such a bad idea, we have a controlled space to operate  
in and we are targeting a finite set of beans representing a well  
defined spec, all of which should eliminate much of the cpu and gc  
traffic.

The effort involved getting json lib configured was not exactly  
lightweight.



Ian

On 10 Feb 2009, at 19:43, Kevin Brown wrote:

> We could also write our own parser. It's not a terribly complex  
> format.

Re: Remove JSON-LIB from codebase?

[Kevin Brown <et...@google.com>]

On Tue, Feb 10, 2009 at 10:30 AM, Ian Boston <ie...@tfd.co.uk> wrote:

> IMHO you cant argue with 10x, and I remember that there were tests to prove
> this at one point so a big +1 to using JsonSerializer for output. I also
> suspect since its smaller that the GC traffic will be lower as well ?


There's a much bigger advantage for GC than for CPU -- we create one buffer
up front and append into it, whereas both the json.org and net.sf variants
create a ton of tiny buffers. net.sf is slightly better, but not by much.
80% of all garbage generated during a gadget rendering request was being
produced by json serialization previously, now it's not even in the top 10.


>
>
> I didn't benchmark org.json for parsing since it needed a lot of coercion
>  to make it work, but although the json lib was fast it had a reasonably
> high GC throughput, that might be an issue. Every little counts.


We could also write our own parser. It's not a terribly complex format.


>
>
> Ian
>
>
> On 10 Feb 2009, at 18:08, Kevin Brown wrote:
>
>  For serialization, JsonSerializer (in common) is at least 10x faster than
>> org.json and at least 5x faster than json lib, as seen by the perf
>> benchmark
>> that I checked in. JsonSerializer does not (currently) serialize beans,
>> but
>> that's an easy addition.
>>
>> Parsing is another story though, and that's where we should focus. Pick
>> one
>> of the two libraries and hide it behind a wrapper and we should be good.
>>
>> On Tue, Feb 10, 2009 at 1:23 AM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>>  I agree we should be down to one, but I am not entirely certain about the
>>> speed as json-lib was developed from the original json org with the
>>> intention of improving speed and flexibility. Evidence is everything, so
>>> before putting the json-lib code in I did some comparative tests that I
>>> posted to the list,(about  july 2008), and I think that json-lib was
>>> faster.
>>> However... we could be talking about different json org libs, the tests
>>> might not have been valid comparisons.
>>>
>>> If its well known that json org is faster then +1 to removing it as a
>>> serializer on that basis.
>>> If someone has done some other tests, then yes +1 to removing it,
>>> If we are not certain some small tests would prove the case.
>>>
>>>
>>> Here are some of the threads in the past
>>> One of the original motivators
>>> http://markmail.org/message/iao6dqngsadgwo3t#query:json%20org%20json
>>> %20lib%20shindig+page:1+mid:7a7vroszjvgblyix+state:results
>>>
>>> The JIRA that added it
>>> http://markmail.org/message/iao6dqngsadgwo3t#query:json%20org%20json
>>> %20lib%20shindig+page:1+mid:rx65qu4aukzgckrv+state:results
>>>
>>> The results from the test done at that time:
>>> INFO SF JSON Lib Output 0.1697 ms/conversion, 35.587204 heap
>>> bytes/conversion,
>>> output packet consumed on average 233.6064 for a string length of 97
>>> [2008-07-18 17:36:50,835] (JsonConverterPerformanceTest.java:142)
>>> INFO Output Was
>>>
>>>
>>> [{"newfield":"nonsense","name":{"unstructured":"robot"},"isOwner":false,"id":"0","isViewer":false}]
>>> [2008-07-18 17:36:50,838] (JsonConverterPerformanceTest.java:148)
>>> INFO SF JSON Lib Input 0.1298 ms/conversion, 217.01837 heap
>>> bytes/conversion,
>>> person object consumed on average 320.088 [2008-07-18 17:36:53,966]
>>> (JsonConverterPerformanceTest.java:179)
>>> INFO ORG JSON Lib Output 0.59 ms/conversion, 34.423996 heap
>>> bytes/conversion,
>>> output packet consumed on average 233.1744 for a string length of 97
>>> [2008-07-18 17:37:00,147] (JsonConverterPerformanceTest.java:213)
>>>
>>>
>>> I think the conclusion that I came to then was that
>>> lib was about 3 times faster for output than the org version. Going from
>>> bean to string. There was no json org string -> bean at the time so I
>>> didnt
>>> do that test.
>>>
>>> This was an unpatched version of json org, and there might be a later
>>> version now, Paul Linder talks about an OOM error for json org and a
>>> patch
>>> to fix is.
>>>
>>> Ian
>>>
>>>
>>>
>>>
>>>
>>> On 10 Feb 2009, at 01:18, Louis Ryan wrote:
>>>
>>> We currently have two JSON bindings in the Java Shindig codebase. The
>>>
>>>> JSON-lib one isnt used (?) and adds a significant amount of code. I
>>>> believe
>>>> that it is faster than the JSON.org implementation but I dont know if we
>>>> have a critical performance need here yet. Id be in favor of removing
>>>> it,
>>>> we
>>>> can always add back later. Thoughts?
>>>>
>>>>
>>>
>>>
>

Re: Remove JSON-LIB from codebase?

[Ian Boston <ie...@tfd.co.uk>]

IMHO you cant argue with 10x, and I remember that there were tests to  
prove this at one point so a big +1 to using JsonSerializer for  
output. I also suspect since its smaller that the GC traffic will be  
lower as well ?

I didn't benchmark org.json for parsing since it needed a lot of  
coercion  to make it work, but although the json lib was fast it had a  
reasonably high GC throughput, that might be an issue. Every little  
counts.

Ian

On 10 Feb 2009, at 18:08, Kevin Brown wrote:

> For serialization, JsonSerializer (in common) is at least 10x faster  
> than
> org.json and at least 5x faster than json lib, as seen by the perf  
> benchmark
> that I checked in. JsonSerializer does not (currently) serialize  
> beans, but
> that's an easy addition.
>
> Parsing is another story though, and that's where we should focus.  
> Pick one
> of the two libraries and hide it behind a wrapper and we should be  
> good.
>
> On Tue, Feb 10, 2009 at 1:23 AM, Ian Boston <ie...@tfd.co.uk> wrote:
>
>> I agree we should be down to one, but I am not entirely certain  
>> about the
>> speed as json-lib was developed from the original json org with the
>> intention of improving speed and flexibility. Evidence is  
>> everything, so
>> before putting the json-lib code in I did some comparative tests  
>> that I
>> posted to the list,(about  july 2008), and I think that json-lib  
>> was faster.
>> However... we could be talking about different json org libs, the  
>> tests
>> might not have been valid comparisons.
>>
>> If its well known that json org is faster then +1 to removing it as a
>> serializer on that basis.
>> If someone has done some other tests, then yes +1 to removing it,
>> If we are not certain some small tests would prove the case.
>>
>>
>> Here are some of the threads in the past
>> One of the original motivators
>> http://markmail.org/message/iao6dqngsadgwo3t#query:json%20org%20json
>> %20lib%20shindig+page:1+mid:7a7vroszjvgblyix+state:results
>>
>> The JIRA that added it
>> http://markmail.org/message/iao6dqngsadgwo3t#query:json%20org%20json
>> %20lib%20shindig+page:1+mid:rx65qu4aukzgckrv+state:results
>>
>> The results from the test done at that time:
>> INFO SF JSON Lib Output 0.1697 ms/conversion, 35.587204 heap
>> bytes/conversion,
>> output packet consumed on average 233.6064 for a string length of 97
>> [2008-07-18 17:36:50,835] (JsonConverterPerformanceTest.java:142)
>> INFO Output Was
>>
>> [{"newfield":"nonsense","name": 
>> {"unstructured":"robot"},"isOwner":false,"id":"0","isViewer":false}]
>> [2008-07-18 17:36:50,838] (JsonConverterPerformanceTest.java:148)
>> INFO SF JSON Lib Input 0.1298 ms/conversion, 217.01837 heap
>> bytes/conversion,
>> person object consumed on average 320.088 [2008-07-18 17:36:53,966]
>> (JsonConverterPerformanceTest.java:179)
>> INFO ORG JSON Lib Output 0.59 ms/conversion, 34.423996 heap
>> bytes/conversion,
>> output packet consumed on average 233.1744 for a string length of 97
>> [2008-07-18 17:37:00,147] (JsonConverterPerformanceTest.java:213)
>>
>>
>> I think the conclusion that I came to then was that
>> lib was about 3 times faster for output than the org version. Going  
>> from
>> bean to string. There was no json org string -> bean at the time so  
>> I didnt
>> do that test.
>>
>> This was an unpatched version of json org, and there might be a later
>> version now, Paul Linder talks about an OOM error for json org and  
>> a patch
>> to fix is.
>>
>> Ian
>>
>>
>>
>>
>>
>> On 10 Feb 2009, at 01:18, Louis Ryan wrote:
>>
>> We currently have two JSON bindings in the Java Shindig codebase. The
>>> JSON-lib one isnt used (?) and adds a significant amount of code. I
>>> believe
>>> that it is faster than the JSON.org implementation but I dont know  
>>> if we
>>> have a critical performance need here yet. Id be in favor of  
>>> removing it,
>>> we
>>> can always add back later. Thoughts?
>>>
>>
>>

Re: Remove JSON-LIB from codebase?

[Kevin Brown <et...@google.com>]

For serialization, JsonSerializer (in common) is at least 10x faster than
org.json and at least 5x faster than json lib, as seen by the perf benchmark
that I checked in. JsonSerializer does not (currently) serialize beans, but
that's an easy addition.

Parsing is another story though, and that's where we should focus. Pick one
of the two libraries and hide it behind a wrapper and we should be good.

On Tue, Feb 10, 2009 at 1:23 AM, Ian Boston <ie...@tfd.co.uk> wrote:

> I agree we should be down to one, but I am not entirely certain about the
> speed as json-lib was developed from the original json org with the
> intention of improving speed and flexibility. Evidence is everything, so
> before putting the json-lib code in I did some comparative tests that I
> posted to the list,(about  july 2008), and I think that json-lib was faster.
> However... we could be talking about different json org libs, the tests
> might not have been valid comparisons.
>
> If its well known that json org is faster then +1 to removing it as a
> serializer on that basis.
> If someone has done some other tests, then yes +1 to removing it,
> If we are not certain some small tests would prove the case.
>
>
> Here are some of the threads in the past
> One of the original motivators
> http://markmail.org/message/iao6dqngsadgwo3t#query:json%20org%20json
> %20lib%20shindig+page:1+mid:7a7vroszjvgblyix+state:results
>
> The JIRA that added it
> http://markmail.org/message/iao6dqngsadgwo3t#query:json%20org%20json
> %20lib%20shindig+page:1+mid:rx65qu4aukzgckrv+state:results
>
> The results from the test done at that time:
> INFO SF JSON Lib Output 0.1697 ms/conversion, 35.587204 heap
> bytes/conversion,
> output packet consumed on average 233.6064 for a string length of 97
> [2008-07-18 17:36:50,835] (JsonConverterPerformanceTest.java:142)
> INFO Output Was
>
> [{"newfield":"nonsense","name":{"unstructured":"robot"},"isOwner":false,"id":"0","isViewer":false}]
> [2008-07-18 17:36:50,838] (JsonConverterPerformanceTest.java:148)
> INFO SF JSON Lib Input 0.1298 ms/conversion, 217.01837 heap
> bytes/conversion,
> person object consumed on average 320.088 [2008-07-18 17:36:53,966]
> (JsonConverterPerformanceTest.java:179)
> INFO ORG JSON Lib Output 0.59 ms/conversion, 34.423996 heap
> bytes/conversion,
> output packet consumed on average 233.1744 for a string length of 97
> [2008-07-18 17:37:00,147] (JsonConverterPerformanceTest.java:213)
>
>
> I think the conclusion that I came to then was that
> lib was about 3 times faster for output than the org version. Going from
> bean to string. There was no json org string -> bean at the time so I didnt
> do that test.
>
> This was an unpatched version of json org, and there might be a later
> version now, Paul Linder talks about an OOM error for json org and a patch
> to fix is.
>
> Ian
>
>
>
>
>
> On 10 Feb 2009, at 01:18, Louis Ryan wrote:
>
>  We currently have two JSON bindings in the Java Shindig codebase. The
>> JSON-lib one isnt used (?) and adds a significant amount of code. I
>> believe
>> that it is faster than the JSON.org implementation but I dont know if we
>> have a critical performance need here yet. Id be in favor of removing it,
>> we
>> can always add back later. Thoughts?
>>
>
>

Re: Remove JSON-LIB from codebase?

[Ian Boston <ie...@tfd.co.uk>]

I agree we should be down to one, but I am not entirely certain about  
the speed as json-lib was developed from the original json org with  
the intention of improving speed and flexibility. Evidence is  
everything, so before putting the json-lib code in I did some  
comparative tests that I posted to the list,(about  july 2008), and I  
think that json-lib was faster. However... we could be talking about  
different json org libs, the tests might not have been valid  
comparisons.

If its well known that json org is faster then +1 to removing it as a  
serializer on that basis.
If someone has done some other tests, then yes +1 to removing it,
If we are not certain some small tests would prove the case.


Here are some of the threads in the past
One of the original motivators
http://markmail.org/message/iao6dqngsadgwo3t#query:json%20org%20json 
%20lib%20shindig+page:1+mid:7a7vroszjvgblyix+state:results

The JIRA that added it
http://markmail.org/message/iao6dqngsadgwo3t#query:json%20org%20json 
%20lib%20shindig+page:1+mid:rx65qu4aukzgckrv+state:results

The results from the test done at that time:
INFO SF JSON Lib Output 0.1697 ms/conversion, 35.587204 heap bytes/ 
conversion,
output packet consumed on average 233.6064 for a string length of 97
[2008-07-18 17:36:50,835] (JsonConverterPerformanceTest.java:142)
INFO Output Was
[{"newfield":"nonsense","name": 
{"unstructured":"robot"},"isOwner":false,"id":"0","isViewer":false}]
[2008-07-18 17:36:50,838] (JsonConverterPerformanceTest.java:148)
INFO SF JSON Lib Input 0.1298 ms/conversion, 217.01837 heap bytes/ 
conversion,
person object consumed on average 320.088 [2008-07-18 17:36:53,966]
(JsonConverterPerformanceTest.java:179)
INFO ORG JSON Lib Output 0.59 ms/conversion, 34.423996 heap bytes/ 
conversion,
output packet consumed on average 233.1744 for a string length of 97
[2008-07-18 17:37:00,147] (JsonConverterPerformanceTest.java:213)


I think the conclusion that I came to then was that
lib was about 3 times faster for output than the org version. Going  
from bean to string. There was no json org string -> bean at the time  
so I didnt do that test.

This was an unpatched version of json org, and there might be a later  
version now, Paul Linder talks about an OOM error for json org and a  
patch to fix is.

Ian




On 10 Feb 2009, at 01:18, Louis Ryan wrote:

> We currently have two JSON bindings in the Java Shindig codebase. The
> JSON-lib one isnt used (?) and adds a significant amount of code. I  
> believe
> that it is faster than the JSON.org implementation but I dont know  
> if we
> have a critical performance need here yet. Id be in favor of  
> removing it, we
> can always add back later. Thoughts?

Re: Remove JSON-LIB from codebase?

[Adam Winer <aw...@google.com>]

+1

On Mon, Feb 9, 2009 at 5:18 PM, Louis Ryan <lr...@google.com> wrote:
> We currently have two JSON bindings in the Java Shindig codebase. The
> JSON-lib one isnt used (?) and adds a significant amount of code. I believe
> that it is faster than the JSON.org implementation but I dont know if we
> have a critical performance need here yet. Id be in favor of removing it, we
> can always add back later. Thoughts?
>