I am still in vacation mode, unil Thursday. Just want to giva some
quick response.
>
> 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.
>
The performance hit comes not only from the extra calls, but also from
the local instances (e.g. out and tagStack) that need to be passed
to the methods. Also the increase in the number of methods in a class
cannot be good to VM performance. Let's hope that Hotspot can do good
job here. We'll have to see.
> 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.
>
This is actually in my plan. It would be relative easy
to collapse consecutive writes. We should also consider the performance
issues Costin raised, and maybe redo the runtime library to achieve better
performance in writing out the String/char[] area. The key here is to
avoid unnecessary copying.
> 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.
>
Believe it or not, tag reuse is also in my plan. I am in active discussion
with Jan Leuhe in the very topic, and we'll have a proposal soon. Our
scheme is very different from the one used in tomcat 3. We want to have
a simple scheme that can reuse tag in the current page, especially tags
in loops. More about this later. Therefore I would not do anything
now that'll make doing tag reuse harder. :-)
> 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.
>
Interpreters with state machines may work well for scriptless pages, and
would be an interesting project. It is however not my current focus for
now.
> Comments?
>
> --
> Denis Benoit
> [EMAIL PROTECTED]
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
