[
https://issues.apache.org/jira/browse/SLING-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154236#comment-13154236
]
Antonio Sanso commented on SLING-2255:
--------------------------------------
Thanks a lot for your comment Carsten.
Yes this
if
(this.factory.getMapEntries().getVanityMaps().containsKey(getPathVanityKey(absPath))){
is supposed to be by "design" in order to match with
..
vanityMaps.put(pVanityPath,entries);
..
I have spot a bug in the #getPathVanityKey method though but can be easily
corrected...
Moreover since I have created the patch I have noticed that this could be
further optimized
This
if
(this.factory.getMapEntries().getVanityMaps().containsKey(getPathVanityKey(absPath))){
for (MapEntry mapEntry :
this.factory.getMapEntries().getResolveVanityMaps()) {
could be replaced with
if
(this.factory.getMapEntries().getVanityMaps().containsKey(getPathVanityKey(absPath))){
MapEntry mapEntry=
this.factory.getMapEntries().getResolveVanityMaps().get(getPathVanityKey(absPath))
avoiding the loop.
Overall I do agree with your comments. The best approach would be a complete
redesign in order to have a more clean approach.
About the two different maps I am not sure if you have noticed that the
semantic for the #getResolveMaps method is the same since it merges and sorts
the two maps.
As you said though this is really in the heart of Sling and any change here
should be done really carefully. A more extensive test coverage might help here
(but I must say the existing one for this area is pretty good).
> Improve JcrResourceResolver#resolve performance when big number of vanityPath
> are present
> -----------------------------------------------------------------------------------------
>
> Key: SLING-2255
> URL: https://issues.apache.org/jira/browse/SLING-2255
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Affects Versions: JCR Resource 2.0.10
> Reporter: Antonio Sanso
> Assignee: Carsten Ziegeler
> Priority: Minor
> Fix For: JCR Resource 2.1.0
>
> Attachments: SLING-2255.txt, performance.pdf
>
>
> At the moment the performance of JcrResourceResolver#resolve is tight with
> the number of sling:vanityPath present in the repository.
> Large number of vanityPath means large response time specially in the worse
> case scenario (namely huge number of vanityPath and request that doesn't
> match any vanityPath) but also in the average cases.
> Sling currently employs generic regexps also for vanityPath, but since the
> regex behind a vanityPath is well know there is room for optimization.
> I'll attach a graphs that shows the situation and a potential patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
