FasterXML / FasterXML/jackson3-dev

Add "per-context" caching of introspection entities (`BasicBeanDescription`?)

Offen
#32 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Keine Sprachdaten
Sterne
6
Forks
0
PR-Merge-Kennzahlen
Keine gemergten PRs in 30 T.

Beschreibung

Since one of bigger costs during initialization (and, for some less optimal cases, not just one-time cost) is introspection of information, it makes sense to try to cache this information somehow.
Unfortunately scoping of caching/reuse is not a trivial thing to do, both regarding what can be reused (can not do per-VM, for example, since mix-ins may vary across mappers), and for how big cache use and how long to retain information.
Finally, there is the question of whether to focus on low-level resolution (`TypeFactory` + `JavaType`; `AnnotatedClass` from `ClassIntrospector`) or for higher-level entites (`BeanDescription`).

But since it is likely that in most cases majority of the costs are for a small number of initial calls (mapper readValue and writeValue), and since highest level artifacts (serializers/deserializers) are quite well cached, perhaps it actually would make sense to do something bit different and:

* Only keep reuse "cache" for duration of context (`DeserializationContext`, `SerializerProvider`) onlt
* Cache intermediate level entities: `BeanDescription` (specifically, `BasicBeanDescription`).

This seems like a potential win because it would tackle one low-hanging fruit; introspection needed for same type via different properties (via different POJOs). And being per-context, it:

1. Need not be thread-safe (only accessed from one thread)
2. Had well-defined lifespan so it's short-term garbage (and does not necessarily need to have bound size -- although as a matter of principle probably still should, can just set to a high value)

So let's consider doing this.

About only (?) challenge is that of verifying efficiency of the approach. Would probably make sense to concoct a test case with large (enough) number of POJOs, then running `jmh` over case of not reusing `ObjectMapper`s, where full introspection cost is incurred for every call.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.