[ 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)