[SLING-4596] Performance: Consider optimizing JcrItemResource#getParent and getChild - ASF JIRA

Attach files

Attach Screenshot

Voters

Watch issue

Watchers

Create sub-task

Link

Clone

Update Comment Author

Replace String in Comment

Update Comment Visibility

Delete Comments

XML

Word

Printable

JSON

Details

Type: Improvement
Status: Resolved
Priority: Critical
Resolution: Won't Fix
Affects Version/s: JCR Resource 2.5.0
Fix Version/s: None
Component/s: JCR, ResourceResolver
Labels:
- performance

Description

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