Here’s why you probably shouldn’t be using the Gson library in 2018
Preface
Gson is the most popular JSON parsing library on GitHub. It has over 13,000 stars and the numbers are only growing. People (including myself) love it for its simplicity and how typing a single line of code converts your JSON to an object and vice-versa.
But did you know that this simplicity comes at a cost?
I began to wonder how different these JSON parsing solutions can be, and how much of a difference there is between a modern solution like Gson compared to something like JSONObject. After realizing that most of the information on the web is outdated I decided to test out some of these solutions myself.
The process of testing JSON parsing solutions
I decided to test the 3 most popular libraries for parsing JSONs (Gson, Jackson and Moshi) and compare them against JSONObject.
In my comparison the parsing solutions would be compared based on 4 factors:
- The time it takes to serialize an object in milliseconds.
- The time it takes to deserialize a JSON in milliseconds.
- The length of the JSON (The amount of characters in the JSON’s String)
- The method count of each of the libraries.
I built 2 heavy object instances (with similar values in them) to test the performance of the libraries and to make sure that they can’t use caching to their advantage (I also tested it out with the same object instance and the results were similar). I ran the test a few times to see how each round affects the behavior of the libraries. Here’s what I found.
The results
These results show how well each JSON parsing library did in accordance to the first 3 of the 4 deciding factors in my comparison that are mentioned above. You can ignore “Object Length”, that one simply represents how many characters there are in my deserialized Object’s toString() method.
Looking at these results we can see that at the first run, all of the solutions seem to perform rather slowly, which is probably due to some behind-the-scenes memory allocation. Looking at the results of the second run we see a clearer picture of how these solutions will perform for most of the application’s run time. And that is where we see the problems presented with using Gson as our JSON parsing library.
Gson is the slowest at deserializing JSONs. It’s almost twice as slow as Moshi and JSONObject and slower than Jackson by more than twice in that regard.
Another thing to take note at is Gson is the only library producing larger JSON Strings than the other solutions. This is because Gson inserts a bunch of escape characters whereas the other solutions serialize the object as-is.
One thing that could be used to Gson’s advantage though is that it indeed does serialize objects relatively fast, but you should also take into consideration that because the actual JSON is bigger (in this case by 24%) it will take up more of your system memory when stored in a String and it will take longer to send in an HTTP request for example.
The fourth deciding factor — method count
Jackson method count: 10,197
Gson method count: 1,036
Moshi method count: 534
Moshi + Okio method count: 1,140
Conclusion
Jackson is by far the heaviest library of them all, but it is also the fastest one. Another great aspect of using Jackson is consistency when building a Java server-side application alongside your Android application, since all JAX-RS implementations and the Spring Framework use Jackson as their JSON parsing library (and we can see why).
Moshi on the other hand, is a very small library if you don’t take into consideration the bundled Okio library (which, if you’re using other popular libraries from Square, which you probably are, is bundled-in anyway) and it performs similarly to JSONObject.
To conclude, I recommend using either Jackson or Moshi for working with JSONs and avoid using Gson in your next project, as it is much slower for deserialization and while marginally faster than Moshi at serializing objects, the resulting JSON might be larger due to the HTML-compatible escape characters that Gson inserts into it.
