Henry Kuijpers created SLING-10899:
--------------------------------------
Summary: Result of JcrNodeResource#adaptTo(ValueMap.class) should
be cached
Key: SLING-10899
URL: https://issues.apache.org/jira/browse/SLING-10899
Project: Sling
Issue Type: Improvement
Components: API, ResourceResolver
Affects Versions: Resource Resolver 1.7.10, API 2.23.6
Reporter: Henry Kuijpers
I was performance testing our application. There is a specific part of the code
where we have a set of ~500 resources and we sort them based on a few
properties of the resources. Multiple properties are used (which results in
multiple calls to getValueMap). The sorting is done using a comparator, so the
logic that determines the order is accessed numerous times.
We've seen quite a decrease in performance when doing this with Resources that
are of type JcrNodeResource. Turns out that the result of getValueMap (or
adaptTo((Value)Map.class)) is not cached.
As you can see in the adaptTo()-method implementation:
https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrNodeResource.java#L136
this call bypasses the AdapterFactory framework and also bypasses any caching
that happens over there.
What's even more unfortunate, is that JcrValueMap is implementing caching via
https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/6e13f4d315ddf2804d2e16c55faee18e805b618e/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java#L49
. That caching is not leveraged properly, because every call to getValueMap
returns a new JcrValueMap, instead of reusing a previously created one.
One change that can be done is maybe converting the logic inside the
adaptTo()-method to a dedicated AdapterFactory implementation, so that caching
is done by default?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
