[
https://issues.apache.org/jira/browse/SLING-10899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17437282#comment-17437282
]
Carsten Ziegeler commented on SLING-10899:
------------------------------------------
The resource resolver does not know anything about the adaptions - if we want
to improve we probably would need to change the resource resolver to keep track
of all resources it handed out and ensure that it returns the same resource
object. That alone is already a heavy change which can lead to problems.
Now, once we have the same resource object, we need to deliver the same
Modifiable(ValueMap) on adaption.
We could of course solve the second one without the first one by just keeping
track in jcr resource.
But then a refresh is still not catched - again with keeping track of
everything we might be able to handle it.
Then comes the problem of the deep value maps acting across resources, this is
where we most likely will loose
And then there is so much code doing modifications directly via the JCR API
(sometimes mixed with resource API usage), and thats where we have to give up.
Or in other words, I don't think that we can easily improve this area without
creating new problems - and that is most likely the reason why the code is how
it is today.
> 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: JCR
> Affects Versions: JCR Resource 3.0.22
> Reporter: Henry Kuijpers
> Assignee: Carsten Ziegeler
> Priority: Major
> Fix For: JCR Resource 3.0.24
>
>
> 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)
