Joel Richard created SLING-4596:
-----------------------------------
Summary: Performance: Consider optimizing
JcrItemResource#getParent and getChild
Key: SLING-4596
URL: https://issues.apache.org/jira/browse/SLING-4596
Project: Sling
Issue Type: Improvement
Components: JCR, ResourceResolver
Affects Versions: JCR Resource 2.5.0
Reporter: Joel Richard
Priority: Critical
I have noticed that on some "resource intensive" pages up to 24% of the
rendering time is spent in AbstractResource.getParent. One of the main reasons
for this is because the ParentHidingHandler traverses for each resource to the
root (see SLING-4568).
getParent is not just called often, but is also about 10 times slower than
jcrNode.getParent() which has the following reasons:
- itemExists is called unnecessary because JcrResourceProvider#createResource
does not know that the path belongs to a parent of a node which has already
been read. See also SLING-4585.
- jcrSession.getItem (which is used to read parents in
JcrResourceProvider#createResource) is about 3.5 times slower than
jcrNode.getParent in Oak.
- Some other overhead which cannot be avoided entirely.
The situation could be improved with a getParent implementation which is
specific to JcrNodeResource and uses getNode().getParent() directly to create a
new JcrNodeResource. I have implemented such a method (see attached
experimental patch) and it reduces the time for getParent from 24% to 5% on my
test page.
As discussed on the [mailing
list|http://mail-archives.apache.org/mod_mbox/sling-dev/201504.mbox/%3C55266BB2.1050506%40apache.org%3E]
this is not a good solution because the parent resource could be backed by
another provider. An alternative approach would be to create a new resource
provider interface which accepts the base resource (which is passed to
resourceResolver.getResource), retrieves the node form it and uses it for a
direct getParent/getNode call (see the linked mail for more information).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
