[
https://issues.apache.org/jira/browse/SLING-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14966431#comment-14966431
]
Tomek Rękawek commented on SLING-4611:
--------------------------------------
SLING-5158 is merged, which means we can apply this patch as well. I'll wait to
the end of the day and apply it if there are no objections.
> 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
> Attachments: SLING-4611.patch, SLING-4611_experimental.patch
>
>
> 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)
