On Fri, 24 May 2002, Kin-Man Chung wrote:
> My proposal to solving this problem is to generate codes for a tag
> handler (including its body) to a separate method. This is only feasible
> if the tag action element and its body does not include any scripting
> elements. The current trend (in the coming JSP1.3) seems to be moving
> to scriptless pages, so this is not as restrictive as it appears.
>
> I don't have a detailed design yet for Generator, but I don't see any
> obvious problems. The recent change in flattening out the try/catch
> blocks complicates things a little, but they are manageable.
>
> There is obviously some performance trade-offs. I really don't like
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.
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]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
