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]
