On Tue, Feb 10, 2009 at 10:30 AM, Ian Boston <[email protected]> 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 <[email protected]> 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? >>>> >>>> >>> >>> >
