tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Lin <tcw00l...@yahoo.com>
Subject Re: [Proposal] Removing 64K limit in jasper 2
Date Mon, 27 May 2002 20:17:33 GMT

I've been giving this topic considerable thought for
the last month. Now that JSTL is getting close to
official release, performance may become a bigger
issue.

I've been evaluating JSTL and experimenting with using
it for complex rendering logic. From what I've seen,
the common pattern of usage tends to have a limited
number of tags, with a few tags use repeatedly.  As
denis pointed out, the performance would improve,
though one other benefit is improved reliability.

In my early benchmarks with JMeter and JProbe, deeply
nested try/catch statements results in excessive GC,
which kills reliability and performance. The work
Denis and Kin-man did recently has improved
performance dramatically for pages with lots of tags.
I have noticed on long tests that memory usage slowly
creeps up until I get "out of memory error".

reusing tags probably won't improve performance by
2-4x, but it should make deployments with JSTL tags
more stable. 

--- Denis Benoit <benoitde@sympatico.ca> wrote:
> On Fri, 24 May 2002, Kin-Man Chung wrote:
> 
> Like Costin, I don't think that there would be much
> performance penalty
> by calling a private method.  In fact, if we want to
> reduce the number
> of "unnecessary" calls, I have another idea...  well
> I have two ideas,
> one of which is not related to the 64 K limit.
> 
> 1. In the generated page, there is a lot of
> consecutive:
> 
> 	out.write("some string");
> 	out.write("another string");
> 	and so on.
> 
>    Why don't we merge all these consecutive strings
> together?
> 
> 	out.write("some string\nanother string");
> 
>    it would greatly reduce the number of write()
> calls.  So it would
>    contribute, in a limited way to reduce the size
> of the _jsp_service()
>    method.  It would be sligthly faster, which is
> not bad :) by reducing
>    the number of method calls.
I'm no expert on JSPTag specs, but a common pattern in
JSTL is the following:
<c:set ..>
 <c:choose>
  <c:when test="${some_state}"/><c:out
value="my_value"/></c:when>
  ....
 </c:choose>
</c:set>

Would the jsp page compilation make the distinction
between <c:out ...> which print out a value and one
that is used in a variable? 

> 
> 2. This one has nothing to do with the size, it's
> just something that I think
>    we should plan for: tag reuse.  Some of the pages
> that have a lot of tags,
>    do so because they have them in an HTML table.  A
> "big" page can reference 
>    80 or so tags, but these tags can represent only
> four or five distinct
>    types.  It is not so difficult to find 80 tags in
> a page, but it would be
>    difficult to find one with 80 _distinct_ tag
> classes!  Most of these tags
>    could be reused, that is we often call:
> 
>    	tag1 = new SomeTag();
>    	tag1.doStartTag();
> 	tag1.doEndTag();
> 	tag1.release();
>    	tag2 = new SomeTag();
>    	tag2.doStartTag();
> 	tag2.doEndTag();
> 	tag2.release();
> 
>   There is no real reason to create a new tag for
> tag2, it could have
>   been replaced by:
> 
>    	tag1 = new SomeTag();
>    	tag1.doStartTag();
> 	tag1.doEndTag();
>    	tag1.doStartTag();
> 	tag1.doEndTag();
> 	tag1.release();
> 
>    Here is the relevant section of the JSP specs (I
> know Kin-Man, you don't need
>    a reminder, but others might :):
> 
>    	"public void release()
> 	 Called on a Tag handler to release state. The page
> compiler guarantees
> 	 that JSP page implementation objects will invoke
> this method on all tag
> 	 handlers, but there may be multiple invocations on
> doStartTag and
> 	 doEndTag in between."
> 
>   So, the specs seem to imply that tag reuse is
> allowed.
> 
> Now, why do I brought about this second point, if it
> is not relevant to the 64K
> limit?  Just that whatever the solution we'll take
> to address the issue, it
> should not make tag reuse impossible.  I agree with
> Kin-Man, Tag will take more
> importance in the future of JSP pages.  So we must
> take whatever measures to
> optimize them.  Most tags won't see a big
> performance boost from reuse, but some
> tags can be pretty hefty, and for them, tag reuse
> can be a big factor.
> 
> Now, there were two approach to the "64K problem". 
> Kin-Man proposed creating
> methods for each custom tags, and Costin proposed a
> state machine.  I tend to
> agree with Kin-Man for one account, at the current
> state of the compiler,
> Kin-Man's method could be done faster.  I don't
> think we should throw away
> the "state machine" implementation, but I see it
> more as a Jasper 3 / Tomcat 5
> thing :)  At that time, it could be further
> investigated the benefits and
> penalties of this approach.  But if we choose to
> delegate each tag to a method,
> I think it would be important to leave the door open
> to tag reuse, that is if we
> do not implement it at the same time.
> 
> Comments?
> 
> -- 
> Denis Benoit
> benoitde@sympatico.ca
> 

Looking at the work on jasper recently and comparing
it to the older tag pooling in 3.3, I lean towards
using the state machine idea. Though it also has a
limit for high concurrency, but those situations
really should go with a non-tag solution to reduce
overhead.

peter lin


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

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


Mime
View raw message