I’m completely clueless as to any assumptions why this might be the case, but all we can say for now is Moshi doesn’t seem to be up there in the performance department if you need straight up hard JSON parsing firepower.Īnd yes, I want to point out once again that I am using Moshi’s codegen capabilities. This trend remained true for multiple runs of the test. They’re all about same for medium tests, and for the long response tests, surprisingly Moshi has the worst performance of the bunch. For short tests, only Gson has a noticeable slower parsing time. 5000 Iterationsįor curiosity, I wanted to see the results if we bumped up the number of iterations yet again. These trends remained true no matter how many times I ran the tests. Jackson and Moshi have medium parsing times, but Jackson seems to have the fastest long response parsing time of the bunch, while Moshi had a slightly faster short response parsing time. It is however the oldest and still 100% Java-based, which may well be a factor considering we are parsing the response into a Kotlin data class. What’s interesting here is that Gson has the worst performance of the 3 for all sizes of JSON responses which is interesting because it’s supposed to be the most simplistic and lacking in features compared to the other 2. Okay now we have some results to talk about. We’ll see if we get different results by having each test parse the response a thousand times each. Another run of the test may show that Moshi has a shorter ‘short’ parse time than Gson, so for all intents and purposes, we’re saying each parser is about equal in this regard.
Do note that these timings may also fluctuate.
As you’d expect, longer JSON files take a little bit longer to parse. There is negligible difference in any of the parsers.
These are tests where each response is parsed only once by each parser. Other things to note that Moshi is making use of its kapt functions, and Jackson is not using any annotations other than (see the post linked in the beginning to see why these could affect performance). I also run a dummy test for each of the parsers to minimise the factor of any first-use-startup time affecting our tests. To avoid having the JVM startup time be a factor, I have one dummy test that runs before any of the actual tests. This post class will of course be slightly varied for their Jackson and Moshi counterparts, but they all achieve the bare syntax needed to parse a post from the above API. The short one has 14 lines of JSON code, the medium one has 602, and the long one has 10106. I also have 3 different JSON responses saved, all lists of the JsonPlaceholder Posts of varying lengths. I have 3 Retrofit interfaces set up, one for each parser. I’ll be running each of these tests at least twice to make sure there aren’t any flukes.ĭo note that this benchmarking test will only cover parsing JSON responses into Java (or well actually, Kotlin) objects and not the other way around. We’ll be running the tests on the JVM and using MockWebServer to return responses of different lengths and we’ll have them returned as RxJava Singles. So we’re going to be doing our own benchmark test for each of these 3 JSON parsers for Android.Įach test is going to be done within the context of Retrofit because that’s how most apps make network calls nowadays. The results weren’t always very consistent across the 3 posts and we can only guess whether this is due to a difference in code or changed performance with updated versions of each library. While this saved me doing the work, it also raised some interesting questions. In that section, comparing their performances, I decided to use 3 other sources which had already done benchmarking for these libraries in the past, dating as recently as 2019. A couple weeks ago, I made a post on Gson vs Jackson vs Moshi by comparing them on a more general sense of view with performance being only one of the 3 criteria.
0 kommentar(er)
