"Craig R. McClanahan" <[EMAIL PROTECTED]> 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 <[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. >
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>
