Custom Tag Implementation seems inefficient

Question

I've been playing around a bit (alright, so maybe not all that much)
          with custom tags, and it seems like the actual implementation of custom
          tags (tag handler object(s) per tag) is much more resource-intensive
          than would be justified. With Weblogic 5.1 SP6, has anyone had the
          opportunity to compare performance of a typical JSP page w/ and w/out
          custom tags?
          My first impression of custom tags was that you could define tags
          and behaviors that the JSP compiler would then compile into your JSP
          class; there would be no performance hit during page execution. The Java
          code used to write these tags would either be included inline in the JSP
          page code, or else act essentially as static (threadsafe) classes into
          which threads executing JSP pages would call into. This approach means
          less resources consumed and less setup/teardown time in exchange for
          fatter JSPC'd code.
          Instead (and correct me if I am wrong), it appears that each
          distinct custom tag has a pool of instantiated handler objects lying
          around in memory, and each time a custom tag is used, there is a
          little performance hit in the setup & teardown of each handler object's
          pageContext, etc...
          Now admittedly, as another poster (I believe Mr. Purdy) pointed out,
          a "little" ain't all that much... unless there are thousands of those
          "little" hits.
          Moreover, I don't see much benefit in having instantiated objects do
          the heavy lifting. I'd rather have my auto-compiled JSP classes be a
          little more bloated than suffer any performance hit. (I do, however,
          like the fact that custom tags allows for cleaner JSP code, not to
          mention makes for a cleaner break between the creative and coding work.)
          For those of you who've had more extensive experience with custom
          tags, am I missing the target? Is the performance hit negligible for
          heavily-used or complex pages? And/or is the performance hit outweighed
          by code and development cleanliness?
          Thanks for any input.
          Jack
          

Answer 1

Hi Sri
          Looks like you've found an inefficiency in WebLogic's JSP compiler - it
          should be reusing tag instances within the same page. BEA should fix this
          hopefully.
          > So even if a page has 4 tags and 100 users, we have 400 objects just
          > because we use tags.
          Sure, assuming you have 100 concurrent users (and 100 threads in the servlet
          engine). Though creating 400 objects is not a big deal in Java; most non
          trivial Java applications / services create millions of objects.
          Its also worth noting that having a seperate object instance per tag per
          calling thread means that you don't have to do any synchronisation in the
          custom tag (since you're guarenteed to be called by one thread only) so you
          get maximum thread throughput at the expense of some object allocation.
          If you really don't like the idea of creating a few java objects per request
          you could use XSLT to post process JSP files to replace tag occurencies with
          Java scriptlets - though I'm not sure the extra complexity and restrictions
          that this mechanism imposes is worth it at all. Custom tags rock! ;-)
          J.
          James Strachan
          =============
          email: [email protected]
          web: http://www.metastuff.com
          "Sri" <[email protected]> wrote in message
          news:[email protected]...
          > This post had some interesting aspects about custom tags that contradict
          > what I see in the generated java code by the JSP container. I am using
          > weblogic 5.1 sp6 and I have a jsp file that uses a custom tag "xyz:for" a
          > couple of times. the tags are not nested.
          > The java code indicates that two separate instances for the "xyz:for" tag
          > were created.
          >
          > try
          >
          > calicothunder_presentation_tags_ForTag_0 = new
          > calico.thunder.presentation.tags.ForTag();
          >
          > ..............
          >
          > } finally
          >
          > if (_calico_thunder_presentation_tags_ForTag_0 != null)
          > calicothunder_presentation_tags_ForTag_0.release();
          > }
          >
          > Further down
          >
          > try {
          > calicothunder_presentation_tags_ForTag_1 = new
          > calico.thunder.presentation.tags.ForTag();
          > ...............
          >
          > } finally
          >
          > if (_calico_thunder_presentation_tags_ForTag_1 != null)
          > calicothunder_presentation_tags_ForTag_1.release();
          > }
          >
          > The code is creating two different objects for every request. It is not
          > reusing the same object.
          > The release is just cleaning up the current instance, which may be garbage
          > collected at some later stage.
          > So even if a page has 4 tags and 100 users, we have 400 objects just
          > because we use tags.
          >
          > Just trying to understand this better..
          > thanks - Sri
          >
          >
          >
          > "James Strachan" <[email protected]> wrote in message
          > news:[email protected]...
          > > Hi Jack
          > >
          > > I think you're right to be concerned and it is a valid concern.
          > >
          > > In the scheme of things in my experience the cost of using custom tags
          is
          > > quite minimal. Tag instances are reused on the same page so if I have
          > > several non-nested <foo:bar> tags on a page the single FooBarTag
          instance
          > > will be reused for each tag occurance.
          > >
          > > Consider other Java code, say, string concatenation. Consider the
          > following
          > > expression.
          > >
          > > String c = a + b;
          > >
          > > Fairly minimal code you might think. However this line actually involves
          > the
          > > creation of a StringBuffer instance, the call of 2 methods and the
          > creation
          > > of a second String object instance (never mind the internal char[]
          object
          > > instance that is created inside the new Strings constructor).
          > >
          > > A typical use of a custom tag involves one object construction, N
          > > setProperty() method calls (one for each attribute of the tag) and the
          > > startTag / endTag method calls.
          > >
          > > So on balance I'd say the custom tags mechanism is quite small and
          > > efficient.
          > >
          > > Though note that if you use large numbers (say hundreds) of different
          > kinds
          > > of tags then you'll have a much greater object allocation overhead.
          > >
          > > --
          > > J.
          > >
          > > James Strachan
          > > =============
          > > email: [email protected]
          > > web: http://www.metastuff.com
          > > "Jack Lin" <[email protected]> wrote in message
          > > news:[email protected]...
          > > > I've been playing around a bit (alright, so maybe not all that much)
          > > > with custom tags, and it seems like the actual implementation of
          custom
          > > > tags (tag handler object(s) per tag) is much more resource-intensive
          > > > than would be justified. With Weblogic 5.1 SP6, has anyone had the
          > > > opportunity to compare performance of a typical JSP page w/ and w/out
          > > > custom tags?
          > > >
          > > > My first impression of custom tags was that you could define tags
          > > > and behaviors that the JSP compiler would then compile into your JSP
          > > > class; there would be no performance hit during page execution. The
          Java
          > > > code used to write these tags would either be included inline in the
          JSP
          > > > page code, or else act essentially as static (threadsafe) classes into
          > > > which threads executing JSP pages would call into. This approach means
          > > > less resources consumed and less setup/teardown time in exchange for
          > > > fatter JSPC'd code.
          > > > Instead (and correct me if I am wrong), it appears that each
          > > > distinct custom tag has a pool of instantiated handler objects lying
          > > > around in memory, and each time a custom tag is used, there is a
          > > > little performance hit in the setup & teardown of each handler
          object's
          > > > pageContext, etc...
          > > > Now admittedly, as another poster (I believe Mr. Purdy) pointed
          out,
          > > > a "little" ain't all that much... unless there are thousands of those
          > > > "little" hits.
          > > > Moreover, I don't see much benefit in having instantiated objects
          do
          > > > the heavy lifting. I'd rather have my auto-compiled JSP classes be a
          > > > little more bloated than suffer any performance hit. (I do, however,
          > > > like the fact that custom tags allows for cleaner JSP code, not to
          > > > mention makes for a cleaner break between the creative and coding
          work.)
          > > >
          > > > For those of you who've had more extensive experience with custom
          > > > tags, am I missing the target? Is the performance hit negligible for
          > > > heavily-used or complex pages? And/or is the performance hit
          outweighed
          > > > by code and development cleanliness?
          > > >
          > > > Thanks for any input.
          > > > Jack
          > > >
          > > >
          > >
          > >
          >
          >