On Thu, 13 Sep 2001, Bob Lee wrote:
> Date: Thu, 13 Sep 2001 18:43:43 -0500
> From: Bob Lee <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: Tag Performance
>
> The only difference between Tag and BodyTag in the Orion implementation is
> in BodyTags, pageContext.pushBody() and pageContext.popBody() are called.
> These methods create (or possibly pull from a pool) a BodyContent object
> (essentially just a JspWriter). Using BodyTag does add a few more lines to
> the produced servlet, but I'm not terribly worried about this.
>
> I tried some spartan tests (I timed how long it took to execute each tag),
> but I could not discern any difference at all.
>
One other implementation difference depends on the way you have defined
the <body-content> element for your tag in the TLD. If you declare body
content of type "tagdependent", the nested body content of the tag is
bufferred up and given to your tag to interpret. If you use body content
of "JSP", it is simply processed in the usual way. You would use
"tagdependent", for example, if you had a JDBC access tag that let the
user specify an SQL statement as the nested body content -- you want your
tag to process that, rather than output anything to the page.
> The reason I'm concerned with this is that I have a super class tag that I
> extend all of the other tags in my project from. It would be more elegant if
> I could abstract out the differences and have a single BodyTag-based super
> class. I guess the real question is does the overhead for creating a new
> JspWriter instance per tag outweigh the design benefits. Right now I don't
> think it does, however you guys have a lot more experience than I do.
>
Is there a compelling reason that a single base class is helpful? When I
designed the custom tags for Struts <http://jakarta.apache.org/struts> I
used subclassing of tag implementation classes heavily where there were
substantial overlap in supported attributes, and/or where I wanted to have
shared functionality that could be overridden. But I never ran into the
need to implement something as a subclass of a BodyTag tag when the tag
itself didn't care about it's body.
IMHO, you *should* be concerned about the performance difference, even if
not apparent in your tests to date:
* Current generations of JSP page compilers are sometimes pretty
inefficient at generating the Java code to implement body tags.
* Smart JSP page compilers will be able to optimize the code for
non-body tags more aggressively than body tags.
* The extra buffering and object creation (or pooling) *does* have
a non-zero cost, even if it is small. Anything that causes you to
use CPU capacity faster than you need to, or causes garbage collection
to run more often than necessary (if BodyContent objects are not
pooled) reduces the scalability of your app.
If there are values in having a common base class, one thing you might
consider is *two* base classes (one for non-body tags and one for body
tags). If you implement the base classes using the Tag and BodyTag
interfaces, you can even have the base class for BodyTag inherit from the
one for Tag.
> Thanks,
> Bob
>
Craig McClanahan
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, September 13, 2001 2:02 AM
> Subject: Re: Tag Performance
>
>
> > It rather depends on what you mean by "performance penalties", but the
> > container will almost certainly not treat them identically.
> >
> > Extending BodyTagSupport instead of TagSupport has a number of
> implications.
> > As Shawn Bayern has noted, using the latter avoids the creation of objects
> > which might otherwise be unnecessary. However, my own experience points to
> a
> > much more serious problem.
> >
> > Many of the people who write JSP pages do not realise that each page will
> be
> > compiled into a Java servlet. Of those that do, many do not realise that
> the
> > entire page will be compiled into a single method. Of those that realise
> > that also, very few realise that there is a JVM-imposed limit on the
> > bytecode size of a compiled Java method.
> >
> > The bottom line is that, if your JSP page generates too much Java code, it
> > will cause the relatively obscure "Illegal target of jump or branch"
> error,
> > which is *extremely* hard to deal with. I tried to describe the options
> > available in this situation in the following reference:
> >
> > http://www.mail-archive.com/[email protected]/msg04902.html
> >
> > --
> > Martin Cooper
> >
> >
> > ----- Original Message -----
> > From: "Bob Lee" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Tuesday, September 11, 2001 3:35 PM
> > Subject: Tag Performance
> >
> >
> > Does extending BodyTagSupport over TagSupport have significant
> > performance penalties, or does the container treat them identically?
> >
> > Thanks,
> > Bob
> >
> >
> >
>
>
