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
