JSON Performance Comparison

As we all know, JSON is a data format unrelated to the platform, so it is also recognized by the majority of programmers. At present, third-party LIB in various JSON formats are emerging one after another, just like Spring Festival, in the face of this, how should we choose? First, let's compare the current problems... syntaxHighlighter. all (); as we all know, JSON is a platform-independent data format, so it is also recognized by programmers. Currently, third-party LIB in various JSON formats is emerging one after another, like spring festival, how can we choose to deal with these problems? First, let's compare the performance of the JSON Parsing Library: json becnhmark1_protolethose test are generate by parrsing 50.000 pre-build json string. to minimize gc effect on login, a new VM is lanched for each Test. new TestsThe runner run on an intel P9700 CPU, using sun JVM 1.6.22 64bit + SSD each using had been lunch 10 times, the best time had been keeped. benchMark run directly after the JVM startupdate on 30 MayJsonIJ version is now 0.2.7Json-smart is now 1.0.6.3argo is now 2.8 BenchMark: benchResult display as % of the fastest API. lower is better, for example 400% means that JSon-smart is 4 times f Aster. test Sojo Argo json-lib JsonMe org. json-Simple Jackson StringTree JsonIJ Json-fast Json-Smartmixte 1 129% 822% 834% 395% 437% 324% 269% 287% 205% 134% text 1 100% 628% 965% 879% 363% 610% 434% 419% 369% 271% 174% int 1 300% 966% 718% 359% 521% 281% 286% 293% 224% 118% unicode 1 100% 177% 674% 549% 218% 445% 351% 315% 216% 256% 147% boole An 1 285% 724% 809% 391% 498% 332% 291% 210% 228% 138% 100% float 1 145% 794% 711% 1 152% 450% 243% 265% 272% 201% 126% 100% TOTAL 1 251% 818% 739% 511% 484% 319% 300% 272% 228% 137% 100% benchMark with preload classesNot updated yetpreloading class look to have no significant effect, due to SSD usage. test JsonIJ Sojo Argo json-lib org. json JsonMe json-Simple Jackson StringTree Json-fast Json-Smartmixte 1 302% 1 150% 804% 858% 452% 365% 323% 258% 275% 133% 100% text 1 772% 1 492% 914% 782% 582% 332% 409% 355% int 1 332% 1 159% 100% 723% 447% 290% 279% 250% 304% 118% unicode N/A 1 100% 185% 674% 538% 448% 216% 358% 280% 216% 135% boolean 1 100% 1 401% 168% 680% 717% 459% 283% 300% 10 0% float 1 024% 1 129% 740% 707% 1 384% 043% 247% 242% 280% 125% total n/A 1 100% 230% 781% 717% 454% 452% 314% 269% 266% Comment by tsaloranta@gmail.com, may 16,201 1 Where is the source? Are you warming up GC (if not, this test is totally meaningless )? What kind of JSON are you parsing? Comment by project member uriel. chemouni, May 16,201 1 Sources are available now: http://json-smart.googlecode.com/svn/trunk/bench/Json Test string generator: http://json-smart.googlecode.com/svn/trunk/bench/src/net/minidev/bench/json/TestData.javaa New JVM is started for each test, GC is never explicitely called. comment by tsaloranta@gmail.com, May 19,201 1 Whops, meant JVM warmed up, not GC. :-) It is necessary to run code to be tested for couple of seconds first on new JVM, before taking measurements; otherwise test is about how fast JVM can load (and possibly inline) bytecode. comment by project member uriel. chemouni, May 23,201 1 Warmed up test is now available. comment by Programm...@gmail.com, Jun 22,201 1 Using the jvm-serializers ( https://github.com/eishay/jvm-serializers/wiki ) Test suite, I get significantly different results. when testing with about 736 bytes of JSON input (in java. lang. string format), my results show the different APIs refreshing in the following order, ranked from fastest to slowest. ser deser totaljson/jackson-databind-strings 6034 8085 14209 json/fastjson-databind 5837 8924 14826 json/json-smart/manual/tree 13104 9644 23182 json/org. json/manual/tree 16404 20039 36526 json/json. simple/manual/tree 15971 21954 38170 json/jsonij-manual/tree 75124 16888 92275 json/argo-manual/tree-builders 176566 51439 228847 json/json-lib-databind 73202 169966 243474 using the json-smart performance as the baseline, here are the same numbers as percentages (rounded to the nearest whole number ). ser deser totaljson/jackson-databind-strings 46% 84% 61% json/fastjson-databind 45% 93% 64% json/json-smart/manual/tree 100% 100% 100% json/org. json/manual/tree 125% 208% 158% json/json. simple/manual/tree 122% 228% 165% json/jsonij-manual/tree 573% 175% 398% json/argo-manual/tree-builders 1347% 533% 987% json/json-lib-databind 559% 1762% 1050% these results place the performance of some of the different APIs in significantly different orders, and some with significantly different percentages. as time permits, I'll try to figure out what the cause of the different results is. (I have no affiliation with any of these projects, or with any other JSON processing project .)