tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Tag object pooling and immutability in the servlet spec
Date Tue, 29 Oct 2002 06:47:24 GMT

"Craig R. McClanahan" <craigmcc@apache.org> wrote in message
news:20021027171704.R78647-100000@icarus.apache.org...
>
>
> 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.
>

Sorry, I was just venting. :(  Once I've managed to squash a Jk2 bug (I sure
don't want to compare the 3.3.1 standalone to the 4.1.13 standalone :), I'll
have a place to start on contributing to Jasper2 (and, really, you've known
me long enough to know that :).

> 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