Description
Hi there,
there is a Jackson-module "Afterburner" available.
As far as I can see, this SDK is not using Afterburner. I suggest trying it.
From my point of view, it seems to be quite promising to improve both SDK cold-start latency as well as SDK performance.
After going through couple of compromises (easy OR compatible), there is one approach that is both easy AND compatible (yay!): Jackson Afterburner Module.
The Afterburner module optimizes the underlying serializers and deserializers.
- Uses byte code generation to replace Java Reflection calls (used for field and method access and constructor calls) with actual byte code -- similar to how one would write explicit field access and method calls from Java code
- Inlines handling of a small set of basic types (String, int, long -- possibly more in future), so that if the default serializer/deserializer is used, calls are replaced by equivalent standard handling (which eliminates a couple of method calls, and possible argument/return value boxing)
- Speculative "match/parsing" of ordered property names, using special matching calls in JsonParser -- this can eliminate symbol table lookups if field names are serialized in the same order that Jackson serializes them (which may be indicated by use of @JsonPropertyOrder)
Since these optimizations more or less mimic more efficient patterns used by "hand-written" converters (i.e. our first option, use of the Streaming API), performance improvements could theoretically reach the level of such converters. In practice, we have observed improvements in 60-70% range of this maximum (that is, Afterburner can eliminate 2/3 of overhead that standard databinding has over hand-written alternatives).
The integration of the module seems to be easy to do. But I cannot overview the effect for people using this SDK.