Performance bottlenecks

I am observing high cpu usage due to extensive usage of JsonPath. Using Java Flight Recording to profile a production machine, these areas standout in JProfiler as cpu hotspots.

1. JsonPath.getPath() This method recursively evaluates the PathToken to build the string representation. In one case we have this in a TreeSet to sort the order of evaluations, and the comparator is surprisingly expensive. Since the JsonPath is compiled and cached, it would make sense for the string representation to be lazily cached (ala String’s hashCode). It may also be faster to replace recursive descent with a loop.

2. JsonContext.pathFromCache(path) This method very inefficiently computes the cache key, resulting in excessive cpu and allocations.

   • When there are no filters, then the path can be used directly as the key.
   • Because the filters is a second arg, “[]”, the concat slow path is used.
   • There is no reason to wrap a list with a LinkedList, as they have the same toString implementation.
   • Arrays.toString would be a more efficient conversion.
   • The operation could use a computeIfAbsent to avoid redundant work on a cache miss due to races.

3. JsonPath.compile(path) This user-facing method creates a new JsonPath instead of using the cache. Therefore if one tries to optimize to bypass the slow pathFromCache call, there is high overhead. The compilation should return the cached copy, allowing the application user to benefit from the configured cache.

4. JsonPath.read(Object, Configuration) This method uses exceptions as ordinary control flow. That is a bad practice because it is slow when many exceptions are created, as filling the stack trace is a costly operation. The internals should return a result object which could be evaluated to the suppressed value.

[ben-manes]

Yes, I think you are finding the same problem as my 4th item. The exception for control flow is pretty bad, as you show.

[richardstartin]

I think these issues are mostly addressed in the latest release.