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
