[
https://issues.apache.org/jira/browse/SLING-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312254#comment-17312254
]
Bertrand Delacretaz commented on SLING-10269:
---------------------------------------------
I'm not sure if the caching as implemented at PR#43 works, using cache keys
which are based on the current resource type + the resource type being checked
for.
Supertypes are defined by each Resource's {{sling:resourceSuperType}} property.
In theory they should be consistent but in practice it's very possible for a
resource A to have type=T1 and supertype=TS, while another resource B has
type=T1 and supertype=TX. Not a good idea probably but possible according to
the current (absence of) rules.
In this case, without caching {{isResourceType(A,TS)}} returns true and
{{isResourceType(B,TS}} returns false.
With the PR#43 caching i think both will return the same value which depends on
which one is called first.
> cache results of isResourceType()
> ---------------------------------
>
> Key: SLING-10269
> URL: https://issues.apache.org/jira/browse/SLING-10269
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.7.2
> Reporter: Joerg Hoh
> Assignee: Joerg Hoh
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I have code, which uses {noformat}resourceResolver.isResourceType(Resource,
> String){noformat} very often to determine type information. I also observed,
> that the execution time of this method contributes a lot to the overall
> execution time.
> Also the number of unique resourcetypes which are going to be checked
> (resource.getResourceType, 1st parameter) is typically quite low; the same
> applies for the number of resourcetypes it is compared against. So it makes
> sense to cache the result of that method call in map which shares the
> lifetime of the ResourceResolver, as the result will never change during this
> lifetime. But during a refresh() this map can be cleared, so any changes in
> the RT hierarchy which might have happened will get effective.
> I have tested this approach already and it gives a significant speedup to my
> code (reduced execution time by 50%); of course this cannot be expected
> universally, as this is an extreme case, but it shows that there is indeed a
> bit of overhead.
> https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/43
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
