[
https://issues.apache.org/jira/browse/SLING-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17312287#comment-17312287
]
Bertrand Delacretaz commented on SLING-10269:
---------------------------------------------
bq. ...wasn't even aware that a resource could define both resourceType and
resourceSuperType, I have never seen it in practice...
I _think_ that's possible but I haven't checked in detail. I suppose it's the
logic of {{getParentResourceType}} and the methods that it calls which define
that, if I'm correct.
> 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)
