Hey everybody,
This may be a bogus thought, so bear with me...
I have been trying to determine why my cache hit ratio is 99%
most of the time, since that seems very high. I have found that there
are many places where my code is evaluating custom tag attributes that
are sometimes constants and sometimes not. For example, sometimes I may
see something like <me:img size="${photo.size}/> whereas other times I
see <me:img size="20"/>. It seems to me that I don't need to call eval()
on expressions that are not expressions at all but "constants", so I
have been gathering some statistics to tell me the ratio of calls that
have "${" in them to calls that do not. What I found is that, of an
average set of custom tag calls, only 5.6% of the expressions I evaluate
contain "${". Now, of the TOTAL evaluate calls made (55% of which are
made using the JSTL tags, 45% by my custom tags), 37.7% of the
expressions contain "${". [My count was taken JUST before checking the
cache for the expressions.] It would therefore seem reasonable that I
could write a method in my base tag to reduce the overhead of
unnecessary evaluation by doing this:
protected String eval(String value) throws JspException {
if (value == null) value = "";
if (value.indexOf("${") >= 0) {
return (String) ExpressionEvaluatorManager.evaluate("", value,
String.class, this, pageContext);
}
else {
return value;
}
}
Would the same change work for the JSTL code also? Does it
already do this?
Are there some expressions which do not have "${" in them that
still need to be parsed into expressions? From [very briefly] looking at
the code, I can find no way that an Expression would be returned without
the String value of the expression containing "${". In fact I read in
the JSTL 1.0 Spec "The EL is envoked exclusively via the construct
${expr}."
It would make sense not to cache the static expressions, since
there is no evaluation work to be saved by caching them (only memory to
be used). Of course, it would appear from my brief scan of the code that
evaluation work is done for them and memory is used caching them.
Does this make sense, or is there something else in the code
already optimizing for this case?
Sincerely,
Daryl.
-----Original Message-----
From: Daryl Beattie [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 21, 2004 10:33 AM
To: 'Tag Libraries Developers List'
Subject: RE: Memory Leak in ELEvaluator.java (standard v1.0.6)
Sounds good to me. Maybe in the documentation we could list the
different cache classes that are bundled the commons code by default.
That way we could include a couple different implementations and have
the users choose from them depending upon usage (much like how the JRE
comes with different GC implementations). That would be ideal. :)
- Daryl.
-----Original Message-----
From: Felipe Leme [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 20, 2004 8:23 PM
To: Tag Libraries Developers List
Subject: RE: Memory Leak in ELEvaluator.java (standard v1.0.6)
On Wed, 2004-10-20 at 16:26, Daryl Beattie wrote:
> Also, do we want to worry about the fact that users of the standard
> taglib have to set some magical (i.e. non-obvious) parameter that will
> make the difference between their system being slow due to
> re-evaluating expressions or taking up huge amounts of memory? They
> might not expect such a thing... It would be nicer if it was somewhat
> self-managing, or at least set to a default value that works for 90%
> of the users. (Maybe I am not in that 90%...)
I think the best solution would be provide some sort of SPI for the
ELEvaluatorCache, for instance, a Config based property that defines the
name of a class that would implement the cache (which in turn would be a
special cache interface or just a POJUM - Plain Old Java Util Map :-).
We could also pass other init-params to fine-tune that cache (and these
parameters would depend on the implementing class). Of course, we would
provide the default implementation that covers the 90% of the cases
(maybe even self-tunable :-) plus lot of documentations.
Actually, we could go one step further and extend this SPI in other
critical places (see for instance
http://issues.apache.org/bugzilla/show_bug.cgi?id=17700 ).
-- Felipe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
