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