Performance impact while using Gson

First of all, thank you for the amazing job with this library.

We are using this library, both via SpringBoot and directly in some services. While troubleshooting some memory issues we found out the next behaviour:

We are generating JWT with 3 timestamps with millisecond accuracy. Those timestamps are using a double format: 12345.6789
Every time a request is received, the JWT is parsed and validated.
While troubleshooting the memory issues we found out that the JWT parsing, via the Gson dependency is generating 3 NumberFormatExceptions for each parsing

The issue is related with the way the Gson library “evaluates” if a Number is Long or Double

    public Number readNumber(JsonReader in) throws IOException, JsonParseException {
      String value = in.nextString();
      try {
        return Long.parseLong(value);
      } catch (NumberFormatException longE) {
        try {
          Double d = Double.valueOf(value);
          if ((d.isInfinite() || d.isNaN()) && !in.isLenient()) {
            throw new MalformedJsonException(
                "JSON forbids NaN and infinities: " + d + "; at path " + in.getPreviousPath());
          }
          return d;
        } catch (NumberFormatException doubleE) {
          throw new JsonParseException(
              "Cannot parse " + value + "; at path " + in.getPreviousPath(), doubleE);
        }
      }
    }

The fact that each parsing is generating an Exception is directly impacting in memory and performance. A simple JUnit test shows the next values

    ToNumberStrategy strategy = ToNumberPolicy.LONG_OR_DOUBLE;
    for (var i = 0; i < 10_000_000; i++) {
      assertThat(strategy.readNumber(fromString("10"))).isEqualTo(10);
    }

Average time of 10 executions: 2s 430ms

    ToNumberStrategy strategy = ToNumberPolicy.LONG_OR_DOUBLE;
    for (var i = 0; i < 10_000_000; i++) {
      assertThat(strategy.readNumber(fromString("10.1"))).isEqualTo(10.1);
    }

Average time of 10 executions: 36s 655ms

1 execution = 1 loop with 10K asserts

The Gson library is in maintenance mode, so pushing any fix there will be problematic. From my POV this situation is bad in 2 different ways:

The current Gson implementation is performing poorly. See a comparison like https://github.com/fabienrenaud/java-json-benchmark
Gson is in maintenance mode, without a release in more than a year an uncertainty about the future

For those reason I think would be interesting to evaluate moving to a different library. I know that in the past json-smart was used and was working relatively well. The project seems to be maintained again, so maybe it’s an option.

‌

Comments (4)