hi felix >Turns out that checking for item existence before accessing the item is >JCR API best practice. So Sling follows best practice.
by using deprecated API? > >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. not sure about the best practices... introducing an new method get*OrNull to Jackrabbit API that is already used everywhere (e.g. JackrabbitSession because it allows you to get the UserManager) that basically comes for free, is IMO preferable over trying to improve the sequence of itemExists/getItem which are prone for regressions and won't work properly for long-living sessions... that's not on a huge effort but one that takes a lot of time with huge regression risk. not sure this is really desirable angela > >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 >
