[
https://issues.apache.org/jira/browse/SLING-3848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Sedding updated SLING-3848:
----------------------------------
Attachment: SLING-3758-jsedding.patch
[~cziegeler], thank you for your changes. However, they do not address the
use-case I meant to describe: iterating over search results without ever
getting their paths.
I attached a patch that illustrates a possible fix. The gist is in
JcrNodeResourceIterator#seek(), where the call to node.getPath() is avoided,
and in JcrItemResource#getPath(), where the "path" field is lazily initialized,
unless it is set in the constructor.
> JcrNodeResource takes too long and initializes too much too soon
> ----------------------------------------------------------------
>
> Key: SLING-3848
> URL: https://issues.apache.org/jira/browse/SLING-3848
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Reporter: Rob Ryan
> Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.3.8, API 2.7.2
>
> Attachments: SLING-3758-jsedding.patch, sling.api.diff,
> sling.jcr.resource.diff
>
>
> In a performance test expected to reflect reasonably real-world conditions
> (50 concurrent users of a mixed load 'forum' type application) I found
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrNodeResource.JcrNodeResource(ResourceResolver,
> Node, ClassLoader) taking more than 20% of time used. The majority of this
> time was spent in setting the resource metadata and to a lesser extent the
> resource type.
> Because the metadata especially is not often accessed and even the resource
> type is not always accessed, delaying these initializations led to a
> noticeable performance improvement.
> The attached patch delays resourcetype lookup and metadata lookups until
> needed.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
