Antonio, Not quite direct evidence, but probably close enough to act on.
+1 BTW: is it the checking for an alias that slows things down, or the resolution of the alias path? If the later, it'd be nice to spit out a warning to the log if we ever find a sling:alias but the configuration is set to ignore it. Jeff. -----Original Message----- From: Antonio Sanso [mailto:[email protected]] Sent: 24 February 2012 13:28 To: [email protected] Subject: Re: [ResourceResolver] sling:alias support Hi Jeff On Feb 24, 2012, at 1:48 PM, Jeff Young wrote: > Felix, > > Have we done any profiling to confirm that sling:alias resolution does > actually contribute a meaningful percentage? we have a Jira ticket somehow related [0]. Not profiling though. There is some kind of profiling for vanityPath [1] as part of [2]. Regards Antonio [0] https://issues.apache.org/jira/browse/SLING-2239 [1] https://issues.apache.org/jira/secure/attachment/12500677/performance.pdf [2] https://issues.apache.org/jira/browse/SLING-2255 > > Jeff. > > > -----Original Message----- > From: Felix Meschberger [mailto:[email protected]] > Sent: 24 February 2012 10:13 > To: [email protected] > Subject: [ResourceResolver] sling:alias support > > Hi all, > > We have had support for sling:alias properties for a long time. This allows > to create URL aliases for example for i18n. Yet, it also creates some > overhead for resolution of non-existing URLs. > > Whenever an URL cannot directly be resolved it is split in segments and the > resource tree is walked down from the top resolving each segment: If a child > resource is not found, all children are inspected for a sling:alias property. > Only if none has been found, the iteration terminates and resource resolution > fails. > > This is potentially a costly operation and may not always be required. > > I wonder, whether we should have a configuration option to be able to switch > off sling:alias support (Default would be enabled sling:alias support for > backwards compatibility). > > Regards > Felix
