Closed Simulant87 closed 2 years ago
I'll incorporate this with the next run of the benchmark (likely in December) to avoid misleading readers which versions are actually being tested.
For the org.json
lib, I intentionally picked the 2009 version since it had always been the most popularly downloaded according to Maven Central (that was true when I wrote this benchmark anyhow), and the version I've always seen been used in legacy projects... I'll take a closer look at this one when I get to run the benchmark against next month or so.
Meanwhile, if you could resolve the few conflicts in build.gradle (just upgraded to v7, uses implementation
instead of compile
, see #35 ), that'd be great.
Thanks.
updated the branch to use gradle 7 compatible implementation
.
I understand your reasoning behind the decision for the org.json
version. Your are right that on https://mvnrepository.com/artifact/org.json/json the version 20090211 has many usages (801). But the version 20160810 has already a slightly higher usage (811) and I am personally interested how the newest version performs. Maybe you can add the results of two different versions, if there is any big difference. This could then also be used as a reference source for an argument to update the library.
My local benchmark shows already a remarkable improvement comparing the newer to the very old version:
Benchmark Mode Cnt Score Error Units Deserialization.orgjson.20210307 thrpt 20 903235,308 ▒ 11347,821 ops/s Deserialization.orgjson.20160810 thrpt 20 899209,279 ▒ 10636,609 ops/s Deserialization.orgjson.20090211 thrpt 20 498577,135 ▒ 18863,520 ops/s
This implements #37
tests pass locally