You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Although it is possible to add local caching for key serializers of Map types, it may make sense to also add global cache, used via SerializerProvider.findKeySerializer(...). This would reduce cost of lookup misses from local cache, or eliminate need for local caches altogether.
The reason caching is important, in general, is that due to extensive configuration via annotations, modular extension mechanisms, optional contextualization and other advanced feature, the actual lookup by type is rather a complicated process. So instead of trying to go crazy optimizing lookups (which may or may not even be possible; any module can request callbacks to be done during lookups) it often makes sense to make sure resulting handler is cached for future (dynamic) lookups.
The text was updated successfully, but these errors were encountered:
cowtowncoder
changed the title
(2.7) Add caching for KeySerializers, similar to regular value serializers
(2.8) Add caching for KeySerializers, similar to regular value serializers
Feb 12, 2016
cowtowncoder
changed the title
(2.8) Add caching for KeySerializers, similar to regular value serializers
Add caching for KeySerializers, similar to regular value serializers
May 4, 2016
At this point question is this: while adding cache would be easy enough, is there data to show that 2 levels of cache (global for serializers, local for "dynamic keys") does not work?
If yes, can be worked on, solve. But right now I don't have anything; and none of test cases (including "wasteful ones") can quite show problem.
(spin-off from #943)
Although it is possible to add local caching for key serializers of
Map
types, it may make sense to also add global cache, used viaSerializerProvider.findKeySerializer(...)
. This would reduce cost of lookup misses from local cache, or eliminate need for local caches altogether.The reason caching is important, in general, is that due to extensive configuration via annotations, modular extension mechanisms, optional contextualization and other advanced feature, the actual lookup by type is rather a complicated process. So instead of trying to go crazy optimizing lookups (which may or may not even be possible; any module can request callbacks to be done during lookups) it often makes sense to make sure resulting handler is cached for future (dynamic) lookups.
The text was updated successfully, but these errors were encountered: