On Sat, 26 Oct 2002, Bill Barker wrote:
> Date: Sat, 26 Oct 2002 23:57:55 -0700 > From: Bill Barker <[EMAIL PROTECTED]> > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Tag object pooling and immutability in the servlet spec > > > "Craig R. McClanahan" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > > > 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>
