FasterXML / FasterXML/jackson3-dev

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

Đang mở
#32 0 bình luận 0 reaction 0 người được giao Xem trên GitHub
Ngôn ngữ chính
Không có dữ liệu ngôn ngữ
Star
6
Fork
0
Chỉ số merge pull request
Không có pull request nào được merge trong 30 ngày

Mô tả

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.

Hướng dẫn đóng góp

Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này

Đánh giá

Issue này chưa được đánh giá.

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.