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]
