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 <[EMAIL PROTECTED]> 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
> [EMAIL PROTECTED]
>
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
