[
https://issues.apache.org/jira/browse/SLING-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492383#comment-14492383
]
Joel Richard commented on SLING-4611:
-------------------------------------
The idea is basically the same as in SLING-4596 just for MergedResource. One
way of implementing it which should work in all cases would be the following:
# Store the mappedResources which are already passed to the MergedResource
constructor in the object.
# Introduce the ResourceProvider API which is described in SLING-4596 and
accepts the base resource for getResource.
# Check in getResource whether the base resource is also MergedResource and if
so get all mapped resources.
# Call getChild for each mapped resource. If the resource is a JcrNodeResource,
it would benefit here from the SLING-4596 optimization.
# Next it would have to check which search paths aren't covered with the mapped
resources and try to get the resources for theses. In most cases getResource
will return null for these (because the parent couldn't be read either).
# Combine the resources from both sources and merge them.
> Performance: Consider optimizing MergedResource#getParent and getChild
> ----------------------------------------------------------------------
>
> Key: SLING-4611
> URL: https://issues.apache.org/jira/browse/SLING-4611
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Affects Versions: Resource Merger 1.2.8
> Reporter: Joel Richard
> Priority: Critical
> Labels: perfomance
>
> For some pages up to 29% of the rendering time is spent in
> AbstractResource.getChild. In my case, 75% of the resources are
> MergedResources and the rest are JcrNodeResources (for which I have already
> opened SLING-4596).
> Therefore, I would suggest implementing the following optimization:
> The merged resources should be stored in MergedResource and when getChild is
> called, it would use getChild on them directly and merge the child resources.
> This would have the advantage that the ParentHidingHandler would not have to
> be called again for the parent resources and could even make SLING-4568
> obsolete. Moreover, it would leverage optimizations of the merged resource
> implementations (e.g. SLING-4596 for JcrNodeResource#getChild).
> A problem with this approach is that possible in JCR (and maybe also some
> other resource providers) to set ACLs which allow to read children but not
> their parents. Therefore, getChild will in addition have to check for each
> search path which isn't covered with a merged resource if this path does
> really not exist.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
