I have created SLING-4596 to track this.
- Joel On 09/04/15 12:08, "Carsten Ziegeler" <[email protected]> wrote: >Am 09.04.15 um 13:44 schrieb Joel Richard: >> Hi Dominik, >> >> Yes, the ResourceProvider API would have to be changed (or a new API, >>e.g. >> OptimizableResourceProvider) be introduced). >> >> If that isn’t an option, then we could either implement a “minicache” >>with >> a ThreadLocal (which comes at a cost as well), think about an even >>uglier >> workaround with the Map<String, String> parameters or consider my >>initial >> proposal again. >> >> Carsten’s objection was the following: >> >> “You don't know whether the parent or any child resource is backed by >>JCR. >> It could be that the parent is delivered by a different resource >>provider >> or that child nodes are a combination of resource providers." >> >> >> Would it be an option to create a utility which can be used in >> getParent/getChild/getChildren to check if the parent/child path is >> handled with the same resource provider? If this check returns true, >>then >> it would execute the optimised methods and otherwise fall back to the >> general methods. I would prefer a new API though. >> > >These are all good ideas and I really appreciate them. But please let's >first >have some performance tests where we can do profiling/benchmarking and >see where the hotspots are. Once we have this we can think about how to >solve them. >I know that you have already done this, but again this has been done >outside of the Sling project (which is neither bad nor a problem) and we >first need >better sharing/visibility of these problems here before we can jump to >conclusions and do something. And we need to set goals and take the >whole picture into account. For example, if you want to get to 50% of >the current rendering time, saving 2% here and there will never get you >there. Or maybe reducing the rendering cost by 5% for your use case >might increase the cost by 3.5% for others. Of course some of the >changes are pretty clear and don't need further discussions. > >Thanks >Carsten >-- >Carsten Ziegeler >Adobe Research Switzerland >[email protected]
