[
https://issues.apache.org/jira/browse/SLING-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated SLING-10269:
------------------------------
Description:
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()}} or {{commit()}} 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
was:
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
> 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
> Fix For: Resource Resolver 1.7.4
>
> Time Spent: 3h 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()}} or {{commit()}} 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)
