[
https://issues.apache.org/jira/browse/SLING-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17316070#comment-17316070
]
Robert Munteanu commented on SLING-10269:
-----------------------------------------
[~joerghoh] - IIUC you're saying that resource type information can be
incorrect even now if modified via the JCR API and already loaded in memory? If
that is the case, do we add any particularly new staleness?
If you find a good place for it you can add a javadoc somewhere that mentions
this pitfall and the workaround ( refreshing the resource resolver ). Maybe in
the supertype check method, saying something like modifying resource type
properties outside the resource api requires a refresh call.
> 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)
