On Apr 9, 2015, at 8:55 AM, Carsten Ziegeler <[email protected]<mailto:[email protected]>> wrote:
Am 09.04.15 um 08:06 schrieb Dominik Süß: Hi Carsten, hi Joel, AFAIU the cost intensive part is the call of createResource() at [0] that will do a look up by path but not utilize the node of the resource issuing this lookup through getParent (indirected via resourceResolver lookup by the AbstractResource). What would you think about "caching" the parentNode when getParent() is called for the ResourceProvider so that as the resourceResolver consults the JCRResourceProvider in the follow up call the parentNode is already present. As we most probably don't have an extremely wild mix of different resourceProviders this caching should only render unnecessary in the rare cases where we have a different ResourceProvider at a higher level without doing any harm but a little bit of memory consumption (feature could be implemented with a on-off switch ;) ) Well, in general I'm against adding small caches all over the place as this will most likely turn into pain over time. And usually it works in one use case but fails (or turns into worse performance) in other use cases. This might not be the case here. I think, before we do any changes we should have test cases where we can check the results against. I trust Joel's analysis, however we don't have any benchmarks in the Sling project and it's very hard atm for the Sling community to see the problem and to verify the implications of a change - being it good or bad. Therefore, let's create a benchmark project as before we might use [0] in order to generate something like [1] regards antonio [0] https://svn.apache.org/repos/asf/sling/trunk/performance/ [1] http://people.apache.org/~asanso/sling/report-2012-08-31/report.html first and use that for improvements. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland [email protected]<mailto:[email protected]>
