Hi Joel Thanks for pointing out. Yet, this has been discussed before.
Turns out that checking for item existence before accessing the item is JCR API best practice. So Sling follows best practice. If this generates a performance problem, I would suggest this to fix in the implementation of the API such that API usage best practice guidelines can be follows. Regarding the performance impact: If this createResource method has such a dramatic impact on request processing performance in Sling, it might be that Session.itemExists and/or Session.getItem methods are really expensive. Which would be yet another reason why we should concentrate on improving the implementation rather than introducing new API. Regards Felix > Am 07.04.2015 um 09:00 schrieb Joel Richard <[email protected]>: > > Hi, > > In JcrResourceProvider.createResource (Sling) it uses fist > Session.itemExists to check whether an item exists and then > Session.getItem to retreive it. Even though the item data is cached for > the second call, this adds 8% overhead to the page rendering. 14% of the > whole page rendering time is spent in itemExists. > > Sling could just only use getItem and catch the exception if the item does > not exist. Unfortunately, this will not perform well if the resource > resolver is often used to read items which do not exist because exceptions > are slow. > > Technically, the simplest solution would be to export the method > getItemOrNull. This method could be Oak-specfic and only be used by Sling > when running on Oak. > > Another approach might be to have the last item cached in the session and > return it immediately if getItem is called right after itemExists. No > doubt, this is ugly and would solve only this specific problem, but since > it is a very common pattern, it could make sense. > > Maybe it is also possible to improve the performance of itemExists itself, > but that's a question which somebody else has to answer. > > - Joel
