Performance Goals: More than microbenchmarks
Our goal is to provide the best library for producing and consuming JSON. We're interested in being efficient along multiple axes.
- CPU Time. Microbenchmark performance is important, but microbenchmarks aren't everything. We're interested in start-up time: how long does a parse take when the JIT hasn't kicked in yet. This is particularly important for client platforms like Android.
- Memory efficiency. Overuse of the application heap for pools improves benchmark performance but hurts total system performance. A large heap also increases the likelihood that an Android application will be evicted while in the background. Gson doesn't use String.intern() which can cause unnecessary strain on the garbage collector.
- Library size. It's unreasonable to expect mobile applications to include large binaries just to wrangle some JSON. We're careful about how big gson.jar is.
- Developer productivity. Fast doesn't matter if the code is unmaintainable. Our library is easy to use, and easy to use efficiently. We're fast by default; we don't require you to muck with tuning knobs to switch from benchmarking mode to production mode.
We try to improve performance on each release. Speed is a feature.Gson 2.1
We started caching type adapters. This significantly reduces the amount of reflection required for binding small documents. We made several local optimizations in JsonReader to save field accesses and improve stream parsing performance.
We changed Gson's internal databinding from tree-based to stream-based. This avoids the need for creating an intermediate tree representation in databinding.
Caching reflective objects in databinding.
Replaced a tree-based parser with a stream-based parser.
We're working to lower the cost of including Gson in your application.
|Release||Size (Kb) |
|2.0 ||199 |
|1.7 ||199 |
|1.6 ||170 |
Here are some external performance comparisons of Gson
- Gson on Android: This is comparing performance of the low-level parser in Gson