Hi Carsten, hi Joel,

AFAIU the cost intensive part is the call of createResource() at [0] that
will do a look up by path but not utilize the node of the resource issuing
this lookup through getParent (indirected via resourceResolver lookup by
the AbstractResource).

What would you think about "caching" the parentNode when getParent() is
called for the ResourceProvider so that as the resourceResolver consults
the JCRResourceProvider in the follow up call the parentNode is already
present.

As we most probably don't have an extremely wild mix of different
resourceProviders this caching should only render unnecessary in the rare
cases where we have a different ResourceProvider at a higher level without
doing any harm but a little bit of memory consumption (feature could be
implemented with a on-off switch ;) )

WDYT?
Dominik

[0]
https://github.com/apache/sling/blob/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProvider.java#L154

On Wed, Apr 8, 2015 at 4:57 PM, Carsten Ziegeler <[email protected]>
wrote:

> Am 08.04.15 um 16:50 schrieb Joel Richard:
> > Hi,
> >
> > I have noticed that on some “resource intensive” pages up to 24% of the
> > rendering time is spent in AbstractResource.getParent(). One of the
> > reasons for this is because the ParentHidingHandler traverses for each
> > resource to the root (see SLING-4568).
> >
> > This 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 getParent method (see attached
> > experimental patch) and it reduces the time for getParent from 24% to 5%
> > on this specific page.
> >
> > Did I miss something or is this is a legitimate change? If so, wouldn’t
> > this also be a possible improvement for getChild and listChildren?
> >
> I think this is not a good idea. You don't know whether the parent or
> any child resource is backed by JCR. It could be that the parent is
> delivered by a different resource provider or that child nodes are a
> combination of resource providers. So all traversal has to go through
> the resource resolver.
>
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> [email protected]
>

Reply via email to