On 5/28/05, Kevin Burton <[EMAIL PROTECTED]> wrote:
> I've been tuning our application trying to get the maximum performance
> out if the system as possible.
> 
> I've been throwing the system at jprofiler and allowing it to tell me
> where to optimized.
> 
> In short Tomcat is slower than our DB, filesystem,. network and all
> other systems by about 4x.
> 
> I've been able to shave some page load time off by some but not enough.
> 
> The problem I'm starting to see is that we just have a large number of
> c:set and c:if constructs (and so forth) within loops.  These loops then
> get executed 5 times and next thing you know it you have 50k taglib calls.
> 
> The problem comes when you look at the source:
> 
> Let's say you start with:
> 
> > <c:set var="foo" value="bar"/>
> 
> This nice little elegant piece of code gets expanded to:
> 
> >   private boolean _jspx_meth_c_set_0(PageContext _jspx_page_context)
> >           throws Throwable {
> >     PageContext pageContext = _jspx_page_context;
> >     JspWriter out = _jspx_page_context.getOut();
> >     //  c:set
> >     org.apache.taglibs.standard.tag.rt.core.SetTag _jspx_th_c_set_0 =
> > (org.apache.taglibs.standard.tag.rt.core.SetTag)
> > _jspx_tagPool_c_set_var_value_nobody.get(org.apache.taglibs.standard.tag.rt.core.SetTag.class);
> >     _jspx_th_c_set_0.setPageContext(_jspx_page_context);
> >     _jspx_th_c_set_0.setParent(null);
> >     _jspx_th_c_set_0.setVar("foo");
> >     _jspx_th_c_set_0.setValue(new String("bar"));
> >     int _jspx_eval_c_set_0 = _jspx_th_c_set_0.doStartTag();
> >     if (_jspx_th_c_set_0.doEndTag() ==
> > javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
> >       return true;
> >     _jspx_tagPool_c_set_var_value_nobody.reuse(_jspx_th_c_set_0);
> >     return false;
> >   }
> 
> Which explains why JSP alone is so amazingly slow!
> 
> 
> I did a comparison of the page performance here and it was 15x slower than 
> just using Java.  So the same "set" operation in Java was 15x faster.
> 
> ... so in short ... does anyone have any way to speed this up?
> 
> The other thing I noticed is that EL is evaluated at runtime (which has to be 
> parsed) and sometimes uses reflections.  Can anyone shed any more light on 
> this and hopefully provide some performance optimization suggestions?

You already posted on this subject. Can you provide any hard data that
a tag invocation is actually slow this time ? Guesses don't really do
it, and profilers are often not very accurate. I'm asking because
while the code is indeed quite verbose, it does not make it slow (all
operations in the code that is cut & pasted are very cheap). The JIT
is supposed to take care of this kind of code very well.

For production configuration for Jasper, see:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/jasper-howto.html#Production%20Configuration

We have a facility in Jasper called tag plugins, which allows
replacing a tag invocation (which cannot be any simpler and still
comply to the specification) by equivalent Java code (so your c:if is
traslated to a regular Java "if"). Support for JSTL is very
incomplete, but you can use that to optimize the few tags that you
think need it. Kin-Man asserted that overall the performance
improvement was small - 10% at most. See package
org.apache.jasper.tagplugins.jstl (which has already an impl for "if"
which could help you out). Feel free to sumit more JSTL tag plugins if
you find it works well.

EL will have to remain interpreted at runtime, but has a cache. I have
not evaluated this performance area yet, however. Other xSP
technologies interpret a lot of things at runtime, and most don't even
rely on compilation (which will likely tend to make them a little
slower, I assume), and the overhead is usually not in the xSP engine,
so I don't see why it would be a major issue here (as long as the impl
is not too stupid, of course).

-- 
xxxxxxxxxxxxxxxxxxxxxxxxx
Rémy Maucherat
Developer & Consultant
JBoss Group (Europe) SàRL
xxxxxxxxxxxxxxxxxxxxxxxxx

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to