Cool, I've been thinking about this recently myself. I'm for caching. We shouldn't see a large impact by not caching, but as we go to more distributed resource resolvers, or if we encounter a situation where the retrieval of a resource is non trivial then this would be a great addition.
-- Jason On Mon, Sep 30, 2019, at 2:51 AM, Carsten Ziegeler wrote: > I guess it's not the resource resolver calling getResource() but code > using the resource resolver calling it over and over again, right? > > It's correct that the javadoc does not state whether a new resource > object is returned or a previous one. Client code should not make any > assumptions about this. So you could return the same object. > > Years ago I did a simple caching implementation for the same reasons you > mention :) and although getResource was called over and over again with > the same path during a single request, the caching did not provide any > significant benefit as not getting the resource but the operations on > the returned resource where the part where most time was spent. That > might have changed, but its something to look at. And obviously instead > of trying to implement lower level caching, its better to avoid the many > calls in the first place. > > Regards > Carsten > > Am 30.09.2019 um 08:00 schrieb Jörg Hoh: > > Hi, > > > > I am currently looking performance-wise on the resourceResolver; I found > > that during request handling a single resource resolver often calls > > getResource() for the same path. And before I start researching ways to > > optimize it (caching is quite obvious), I would like know about the > > detailed semantics of getResource(). > > > > Resource r1 = resourceResolver.getResource(path); > > Resource r2 = resourceResolver.getResource(path); > > > > I haven't in the javadoc any statement about the relation between these > > two, especially if it's mandatory that r1 != r2 (which is the current > > implementation). If there are requirements towards this, I would try to > > come up with an implementation in which r1 == r2. > > > > WDYT? > > > > Jörg > > > > -- > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] >
