[
https://issues.apache.org/jira/browse/SLING-3844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14177271#comment-14177271
]
Rob Ryan commented on SLING-3844:
---------------------------------
[~asanso] I agree that in the typical case this will likely prove adequate.
But why set ourselves up for the potential pitfall of the multi-alias case
(even it it is vanishingly rare)? As opposed to mirroring the existing
datastructure in the inverse?
Anyway, I don't object to this so much as to veto it :-) even if I had a veto
vote.
> Resolver.map() spends too much time looking up sling:alias
> ----------------------------------------------------------
>
> Key: SLING-3844
> URL: https://issues.apache.org/jira/browse/SLING-3844
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.1.0
> Reporter: Rob Ryan
> Assignee: Antonio Sanso
> Labels: Performance
> Attachments: sling.resourceresolver.diff
>
>
> In a performance test expected to reflect reasonably real-world conditions
> (50 concurrent users of a mixed load 'forum' type application) I found
> Resolver.map taking more that 30% of the time used. This was tracked
> primarily to checking each path element of the mapped path for sling:alias
> properties to substitute into the result.
> In consultation with [~cziegeler] and [~asanso] I proceeded to implement the
> inverse of Antonio's work on sling:alias for Resolver.resolve. The resulting
> patch is attached. In our case the Resolver.map cost fell from 30% of time
> used to 5%.
> If the resource.resolver.optimize.alias.resolution setting of the Apache
> Sling Resource Resolver Factory is set to false then the patch fallback to
> the original method of finding aliases. When the optimization is enabled the
> aliases are looked up in hash maps maintained by observation and queries for
> sling:alias along the same lines as Antonio's work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
