[
https://issues.apache.org/jira/browse/SLING-12217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18071192#comment-18071192
]
Joerg Hoh commented on SLING-12217:
-----------------------------------
I looked into that issue again, and I would start by checking the
[JavaUseProvider::loadObject()|https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/f7f73e2feefb39a4496a85a093fe834aca92fb01/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/use/JavaUseProvider.java#L178-L206]
method. It uses the "canCreateModelFromAdaptable" - "createModel" pattern, and
in both implementations {{getImplementationTypeForAdapterType()}} is invoked
with the identical parameters.
This could be optimized by a new
{{ModelAdapterFactory.tryCreateModelFromAdaptable()}} method, which internally
encapsulates both the check and the actual adaption, but just with 1 call to
{{getImplementationTypeForAdapterType()}}. This would mean:
* In case the adaption succeeds at any of the 3 conditions, we avoid 1 call to
{{getImplementationTypeForAdapterType()}}.
* in case there is not matching adapter, we execute 3 times
{{getImplementationTypeForAdapterType()}}, which is no change compared to the
existing implementation.
With this change we probably do not reach all goals wrt efficiency (we could
still end up resolving resources multiple times), but we could get around using
caches, which all come with their own problems.
> Reduce resource lookups in Sling Model resolution
> -------------------------------------------------
>
> Key: SLING-12217
> URL: https://issues.apache.org/jira/browse/SLING-12217
> Project: Sling
> Issue Type: Task
> Components: Sling Models
> Affects Versions: Models Implementation 1.6.4
> Reporter: Joerg Hoh
> Priority: Major
>
> While analyzing repository access, I found a pattern in the Scripting HTL
> implementation, which leads to multiple invocations of the same check on the
> same resources in the Sling Model ModelAdapterFactory.
> Invocation at
> [JavaUseProvider.loadObject()|https://github.com/apache/sling-org-apache-sling-scripting-sightly/blob/690a818692bd08c3f6a49e842ea530cc3e60e3ad/src/main/java/org/apache/sling/scripting/sightly/impl/engine/extension/use/JavaUseProvider.java#L172]:
> * modelAdapterFactory.canCreateModelFromAdaptable()
> * modelAdapterFactory.createModel
> those methods directly or indirectly call
> [org.apache.sling.models.impl.AdapterImplementations.lookup()|https://github.com/apache/sling-org-apache-sling-models-impl/blob/cf088713c402177b9d96a5229567804510ef9918/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java#L192],
> which calls
> [getModelClassForResource|https://github.com/apache/sling-org-apache-sling-models-impl/blob/cf088713c402177b9d96a5229567804510ef9918/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java#L302];
> and there multiple resources are resolved, based on the provided
> resourceType.
> I benchmarked this code using a simple AEM sample page (WKND) using HTL and
> Sling Models. I found this code is responsible to the creation of 712 JCR
> Node resource objects (the total page rendering triggered the creation of
> more than 10k, so these are around 7%). When deduplicating the requested
> paths, I found that only 36 distinct paths were resolved with these 712 JCR
> Node resources.
> That means that with proper caching (probably using the
> ResourceResolver.getPropertyMap) around 6.5% of repository access could be
> avoided, leading to a page rendering improvement in about the same range.
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
