MergingResourcePicker optimisation

[Joel Richard <jo...@adobe.com>]

Hi,

With the new ResourceProvider API, the Merging ResourcePicker has already much less overhead. Nevertheless, there is still quite some potential which I would like to discuss here:

Let’s assume that we have two base paths, /libs and /apps. In most cases, the resources from /libs are not overlaid in /apps. If we want to get a resource from /mnt/overlay, then we are obviously forced to check both base paths if the resource exists there. However, if we later use getChild to retrieve a child resource, it would be much more efficient to simply ignore all base paths where the parent resource does not exist.

Moreover, the MergingResourceProvider will check for each overlying resource if the parent resource has a sling:hideChildren property. Even if the child does not exist, it has still to use a getResource call to check if the parent exists and has such a property because if so then it would affect the underlying resource as well. Therefore, it would be better to read in the MergingResourcePicker for overlying resource first the parent and only if it exists the child. If the parent or child does not exist, it could create a special NonExistingResource which has a getParent method which returns the previously read parent.

Unfortunately, both of these optimisations are not entirely correct because in some ResourceProviders it is possible to configure ACLs so that the parent of a readable child is not readable. Personally, I don’t think it’s acceptable that a use case which is rarely used has such a big impact on the performance. Therefore, I am wondering what to do here.

- Should we just accept the current situation?
- Should we implement these optimisations anyway?
- Should we cache paths of non-existing overlying resources?
- Should we use an admin/service resource resolver to get an idea of the real structure of the overlays?

I fear there is no good solution for this problem, but I hope that somebody has another idea what could be done here.

- Joel

Re: MergingResourcePicker optimisation

[Carsten Ziegeler <cz...@apache.org>]

Hi,

I would definitely rule out 3) and 4), They add too much complexity for
this.
Implementing some optimization with knowing that it is not correct,
sounds not like a good idea either. This is bound to fail and
potentially only at a later stage.

Therefore, this leaves me with solution 1 - accepting the situation.

The MRP is hopefully not used that much.

Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Re: MergingResourcePicker optimisation

[Carsten Ziegeler <cz...@apache.org>]

Am 16.10.15 um 11:38 schrieb Joel Richard:
> Hi,
> 
> With the new ResourceProvider API, the Merging ResourcePicker has already much less overhead. Nevertheless, there is still quite some potential which I would like to discuss here:
> 
> Let’s assume that we have two base paths, /libs and /apps. In most cases, the resources from /libs are not overlaid in /apps. If we want to get a resource from /mnt/overlay, then we are obviously forced to check both base paths if the resource exists there. However, if we later use getChild to retrieve a child resource, it would be much more efficient to simply ignore all base paths where the parent resource does not exist.
> 
> Moreover, the MergingResourceProvider will check for each overlying resource if the parent resource has a sling:hideChildren property. Even if the child does not exist, it has still to use a getResource call to check if the parent exists and has such a property because if so then it would affect the underlying resource as well. Therefore, it would be better to read in the MergingResourcePicker for overlying resource first the parent and only if it exists the child. If the parent or child does not exist, it could create a special NonExistingResource which has a getParent method which returns the previously read parent.
> 
> Unfortunately, both of these optimisations are not entirely correct because in some ResourceProviders it is possible to configure ACLs so that the parent of a readable child is not readable. Personally, I don’t think it’s acceptable that a use case which is rarely used has such a big impact on the performance. Therefore, I am wondering what to do here.
> 
> - Should we just accept the current situation?
> - Should we implement these optimisations anyway?
> - Should we cache paths of non-existing overlying resources?
> - Should we use an admin/service resource resolver to get an idea of the real structure of the overlays?
> 
> I fear there is no good solution for this problem, but I hope that somebody has another idea what could be done here.
> 

Thinking about this again :) We could apply the optimisations and simply
see how it goes. If there are problems, we can make it configurable
either with a global switch or even path based.

Regards
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org