"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 :). Since, at the moment, there is no (practical) way to disable tag-pooling, I'll have to wait until I disable it in the build to know for sure if this is why it is so slow. > > If tag reuse really makes your tags more complex, you're probably > designing them wrong (and I'm talking to myself as well; I've been guilty > of that particular mistake). > > > Also, on the immutable object topic, it seems that it would be better to > > have all the initialization of servlets and filters done in the > > constructor, not by calling an init function. If everything could be > > set in the constructor, then all instance fields could be private final, > > meaning that the servlet or filter object could be immutable, and > > therefore known to be threadsafe, which is an issue with servlets. Any > > chance of these changes happening in future releases of the servlet > > spec? > > > > The constructor of a Servlet (or Filter) doesn't have access to the > ServletConfig (or FilterConfig) object, so it cannot acquire > initialization parameters, a reference to the ServletContext instance, or > anything like that. > > Because javax.servlet.Servlet and javax.servlet.Filter are interfaces (not > classes), you can't declare constructors in them. Therefore, the servlet > spec requires that there be a zero-args constructor available so that > instances can be dynamically instantiated. > > Would it be possible to require servlets and filters to have a constructor > that takes a ServletConfig (or FilterConfig) argument? Sure ... at the > cost of breaking every Servlet or Filter that has ever been written. > Doesn't seem like a smart idea to implement something that is purely > cosmetic, and wouldn't change the actual functionality provided by the > container. There's much more important things for the spec to address. > > > Thanks > > Craig McClanahan -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
