tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Tag object pooling and immutability in the servlet spec
Date Mon, 28 Oct 2002 01:24:15 GMT


On Sat, 26 Oct 2002, Bill Barker wrote:

> Date: Sat, 26 Oct 2002 23:57:55 -0700
> From: Bill Barker <res0ob23@verizon.net>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: Re: Tag object pooling and immutability in the servlet spec
>
>
> "Craig R. McClanahan" <craigmcc@apache.org> wrote in message
> news:20021025095901.K36250-100000@icarus.apache.org...
> >
> >
> > On 24 Oct 2002, Mr. Tomcat wrote:
> >
> > > Date: 24 Oct 2002 17:37:36 -1000
> > > From: Mr. Tomcat <tomcat@mobile.mp>
> > > Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> > > To: tomcat-user@jakarta.apache.org
> > > Subject: Tag object pooling and immutability in the servlet spec
> > >
> > > Is there a way to turn off tag object pooling?  Object pooling was a
> > > cool performance technique in earlier versions of Java, but now object
> > > creation is very fast, so it no longer serves a performance function,
> > > and it introduces extra complexity into tag object design.  Is this
> > > misfeature going to be phased out?
> > >
> >
> > No.  Your assumption that it "no longer serves a performance function" is
> > not correct.
> >
> > Just as an example of why it still matters, consider something like this
> > (using the JSTL iteration tag):
> >
> >     <c:forEach var="i" begin="0" end="999">
> >       <mytags:foo index="${i}" .../>
> >     </c:forEach>
> >
> > The tag reuse mechanisms allow a page compiler to create one instance of
> > the <mytags:foo. tag and reuse it for every iteration through the loop,
> > instead of creating 1000 of them.  No matter how cheap object creation
> > gets, there is still a difference -- and that difference is still
> > significant on webapps with large numbers of users.
>
> While I haven't tracked it down completely, this is my favorite bug-bear for
> the 4.1.x (lack of) performance wrt JSPs.  What Craig isn't telling you is
> that 4.1.x will issue 2000 calls to synchronized methods to allocate/release
> the tags in the above example.  That's got to hurt :).

I tried to very precise in my wording, but obviously didn't succeed at
making an important point.  The JSP specification's description of tag
lifecycle (i.e. the ability to allocate an instance and then use it
multiple times before releasing it) makes the optimization I described
*possible* -- that has nothing to do with whether a particular
implementation of the page compiler actually implements it.  And, AFAIK,
Jaser2 does not (yet)  implement this feature.

When this optimization is actually implemented, there will be *one*
allocation and *one* release of the instance for the <mytags:foo> tag in
the loop above, whether or not tag instance pooling is actually used.

One of the primary goals of creating Jasper2 was to make it possible to
implement optimizations like this, by having the page compiler retain
sufficient information about the parse tree to implement things like this
(which optimizing compilers have been doing to programming languages for a
couple of decades now).  With Jasper1, it was basically not feasible,
because the page compiler retained essentially no state information about
the source code of the page.

Craig


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message