Created attachment 29393 [details]
Comparison test case

CustomizedELResolver is to simplify and make it efficient for EL resolving.

1. The code in CustomizedELResolver is copied from CompositeELResolver.
 2. Performance tuning is focus on getValue, because it was the big hotspot of one page hit if the page includes many ELs.
 3. getValue switchs by "base"
 If the base is null, it follows next steps to check value,
 A. ImplicitObjectELResolverImpl(Optimized from ImplicitObjectELResolverImpl)
 B. Extended ELResolvers
 C. ScopedAttributeELResolverImpl(Extends ScopedAttributeELResolverImpl, supports get value by property name)

 Else the base is not null, it checks extended ELResolvers first, then tries to get value from Map, ResourceBundle, List, Array or Bean one by one until the property was resolved.

Q: Why split extSize == 1 to another block ?
 A: To avoid an additional "context.setPropertyResolved(false);"

Q: Why check value from Map, ResourceBundle, List and Array directly in CustomizedELResolver ?
 A To avoid extra valiation in ELResolver.getValue.

Description for attached files.
 1. CustomizedELResolver: The implementation for this fix.
 2 JspApplicationContextImpl.diff : Patch for how to apply this new resolver.
 3. ScopedAttributeELResolverImpl.java: Extension of ScopedAttributeELResolverImpl.
 4. TestPageContext.java: Test case to compare the new ELResolver with CompositeELResolver
 5. ImplicitObjectELResolverImpl.java: related with another bugzilla https://issues.apache.org/bugzilla/show_bug.cgi?id=53895