tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Gonzalez <>
Subject Re : Re : Re : Re : Re : Performance issue in simpleTags and tagfiles
Date Thu, 08 Sep 2011 11:19:56 GMT
Thanks Mark !

> It should be possible to cache the ValueExpression per JSP page (in the PageContext)

Yes, but the PageContext life's span is more or less a user request, no ?
In this case, ValueExpression caching will only be usefull when exactly the same expression
is used multiple times in the same JSP. And I agree that we are improving there a micro-benchmark.

What I was thinking was more about caching ValueExpression per class of JSP (i.e. one cache
for - the cache being shared by all users of the application.


----- Mail original -----
De : Mark Thomas <>
À : Tomcat Users List <>
Cc : 
Envoyé le : Jeudi 8 Septembre 2011 13h09
Objet : Re: Re : Re : Re : Re : Performance issue in simpleTags and tagfiles

On 08/09/2011 10:40, Adrian Gonzalez wrote:
>> The parsed expressions are already cached. I don't think there is
>> any scope for further caching here.
> Parsed expressions are cached as org.apache.el.parser.Node instances
> (in ExpressionBuilder#createNodeInternal) - if I understood
> correctly.


> What I was think was to cache javax.el.ValueExpression
> instances, but not sure if it's correct to cache those instances
> (what's scope ?).

This isn't the biggest delay in my profiling (I use YourKit) whether I
use sampling or tracing which just goes to show how much variation you
can get from system to system and with different profilers. In my
results, annotation scanning is still an issue for postConstruct /
preDestroy. Enhancing the caching to handle these as well gives the
following (with profiling disabled):

The figures I saw were:
Test    OP      Me      Cached  Cached2
tagfile 500     328     203     125
classic 100     141     156     141
simple  500     250     156     125
none    94      140     156     141

I've added that caching to trunk and tc7.0.x/trunk.

With that problem fixed, the sampling and tracing show very different
results which suggests to me that the tracing overhead is starting to
dominate the results.

> For instance, in a jsp compiled code, we have multiple calls to
> PageContextImpl.proprietaryEvaluate. proprietaryEvaluate calls
> createValueExpression and getValue.
> In a sample * 28% of proprietaryEvaluate time is spent on
> createValueExpression, * 45% is spent on getValue

The results of getValue can't be cached since the values of the resolved
attributes may change between invocations.

It should be possible to cache the ValueExpression per JSP page (in the
PageContext) but I am not sure how much that will gain you. We may be
into the realm of improving the results of a micro benchmark rather than
generally improving performance. I'll take a look.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message