tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ian Tomey" <Ian.To...@lombardrisk.com>
Subject Re: any plans to make taglibs EL nativly compile?
Date Fri, 02 Aug 2002 09:17:20 GMT
 
sorry for out of band text here but I just cannot make this mailreader (groupwise) indent
stuff
 
I didn't realise the tags were caching the expressions - I've seen that now (and its
cool).
 
I think any potential benefit of moving to native code is really only going to hit with
'simple' expressions such as bean access ( ie ${a.b} ) rather than full expressions ( ie
${a + b = c} ). In cases like the bean access the amount of overhead of going down the 5/6
levels of function calls plus multiple try....catch blocks to reach the parsed expression
is going to be much greater than the simple code executed to do the access.
 
Anything with mathematical operators then benefit will be much smaller (and the amount of
effort required to write the code does not justify it).
 
For my part, most of the tags that I use are simply iteration and writing out results. On
some pages there can be quite a bit of this information and so a native version of <c:out
value="${a.b}"/> would save a lot of time. Simple tests such as ${a.b==null} or
${a.b==false} would also be easy to compile and provide a useful speed boost being another
set of common tests inside iterations.
 
Regards
Ian
 


>>> bayern@essentially.net 08/01/02 06:08pm >>>
On Thu, 1 Aug 2002, Ian Tomey wrote:

> Just wondering if there were plans afoot to get the EL to compile to
> native code? bit quicker than intrepreting the expression every
> time...

We've considered this, and it is still part of the plan.  It's much more
feasible to attempt this with JSP 2.0 than with JSTL 1.0, for the
container already generates and compiles Java source (while JSTL 1.0
doesn't, and so would have to do so out-of-band).

Even then, however, it's not clear how beneficial the optimizations will
be.  Consider a sample expression like ${a.b}.  This expression means
vastly different things (at the Java-code level) if 'a' is a Map than if
'a' is a JavaBean.  But this information is only available at runtime.

It's possible to capture some of the structure of an EL expression in
compiled code, as with ${a + b = c}.  But even then, the type conversions
depend partly on information only available on runtime, meaning a fairly
thick runtime support library and, ultimately, diminishing returns with
respect to performance improvements.

Right now, the Jakarta implementation of JSTL caches all expressions,
meaning they don't need to be re-parsed when they're encountered.  My fear
is that this accommodates perhaps 90% of the performance improvement you'd
see with compiled expressions -- although this is just a guess.  More work
indeed needs to be done to determine how beneficial the optimizations will
be.  (If anyone's interested in contributing to this work, please let me
know, and I'll relay it to the JSR-152 spec leads.)

-- 
Shawn Bayern
"JSTL in Action"   http://www.jstlbook.com 


--
To unsubscribe, e-mail:   <mailto:taglibs-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:taglibs-user-help@jakarta.apache.org>



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message