Hi Stefan, long-running resource resolvers are indeed an antipattern, but as the state does not change by default (unless a refresh is explicitly called), it should not be a problem in the first place.
I could imagine that the typical "entrypoints" into caconfig, for example configurationResourceResolver.getResource and configurationResourceResolver.getResourceCollection are responsible to check if a result for the provided parameters are already cached. I cannot speak of any hotspots, as these are highly dependent on the usecase, Jörg Am Di., 15. Nov. 2022 um 11:26 Uhr schrieb Stefan Seifert <stefan.seif...@diva-e.com.invalid>: > hello jörg. > > yes, i assume there is room for improvement here. due to all the possible > inheritance concepts, a lot of calls have to be made to follow that > inheritance chain. > > introducing caching layers may help, as usual we have to do it with care. > although an antipattern it might be possible a resource resolver is used > long-living e.g. in an OSGi service. > > did you already collect some statistic data and identified some hotspots > you want to look upon? > > stefan > > > -----Original Message----- > > From: Jörg Hoh <jhoh...@googlemail.com.INVALID> > > Sent: Tuesday, November 15, 2022 11:12 AM > > To: Sling Developers List <dev@sling.apache.org> > > Subject: Performance of caconfig > > > > Hi all, > > > > I am currently looking into improving performance by reducing the access > > to the Sling repository. And I also came across usage of context-aware > > configuration (caconfig), which can do a lot of repository calls. > > Unfortunately I also found a pattern, that the same (?) call to caconfig > > was done by many components on the same page. Given the nature of the > > Sling repository, all these calls should return with the same result. > > While I tried to optimize this on the component level I ialso understood, > > that this is not always possible, and that we should rather do this at > the > > level of caconfig. > > > > What is your opinion on that? I think that we could use the new > > "resourceResolver.getPropertyMap()" feature to cache the results of a > > caconfig lookup; that cache would actually share the lifetime of the > > resourceResolver and thus be well suited to cache such data. > > > > Jörg > > > > > > > > > > -- > > Cheers, > > Jörg Hoh, > > > > https://cqdump.joerghoh.de > > Twitter: @joerghoh > -- Cheers, Jörg Hoh, https://cqdump.joerghoh.de Twitter: @joerghoh
