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.