Hi,
when migrating from Tomcat7 to Tomcat8 for an application using javax-el
expression evaluation on every request, we noticed a significant
performance impact.
Analyzing it, we see that a call sequence like for
ValueExpression.getValue():
ExpressionFactory expressionFactory = new ExpressionFactoryImpl();
CompositeELResolver elResolver = new CompositeELResolver();
elResolver.add(new ArrayELResolver());
elResolver.add(new ListELResolver());
elResolver.add(new BeanELResolver());
elResolver.add(new MapELResolver());
elContext = new ELContext() {
public ELResolver getELResolver() {return elResolver;}
}
ValueExpression ve =
expressionFactory.createValueExpression(elContext, "...",
Object.class);
final Object result = ve.getValue(elContext);
calls in tomcat-jasper-el:7.0.8:
* valueExpressionLiteral.getValue(context);
* ELSupport.coerceToType(Object obj = "foo", Class<?> type =
java.lang.Object.class)
* returns "foo"
whereas in org.mortbay.jasper:apache-el:8.0.33, the call becomes
* valueExpressionLiteral.getValue(context);
* ELContext.convertToType(Object obj = "foo", Class<?> type =
java.lang.Object.class)
* elresolver.convertToType(this, obj, type); // returns null
* ELManager.getExpressionFactory().coerceToType(obj, type)
* ELSupport.coerceToType(Object obj = "foo", Class<?> type =
java.lang.Object.class)
The getExpressionFactory() step in particular seems to cause harm in
the server environment due to the impact of the ReadWriteLock.
Note that what happens here is only the attempt to coerce the String
"foo" to class Object.
So the additional indirections added to
valueExpressionLiteral.getValue() seem to be quite unnecessary for
coercions to Object or to a class that the value is assignable from.
And those indirections hurt performance badly.
So I wonder whether this is a bug/weakness that should be adressed (I
can provide a more reproducible example than baove in that case), or
whether there is a simple ELResolver class that we should add to our
CompositeELResolver to avoid this overhead.
