Casey Lucas wrote:
> Also, did you run the
> tests with and without tag pooling enabled on the same version of
> tomcat? (By adding removing TagPoolManagerInterceptor.)
Yes. The only thing changed between the runs was the TPMI flag.
> > This is a bad design. Basically, any gains you get from reusing tags are
> > lost due to the overhead and general performance decrease you get by
> > using hashtables+"synchronized".
> >
>
> Hash lookup is done once per jsp page - when the jsp page is first run.
> After that, it's basically a synchronized push / pop pair on all subsequent
> runs of the page. In the future we can even get rid of the synch by using
> thread local storage... one step at a time though. :)
Yup, that might improve things. Although then it depends on how
ThreadLocal is implemented. I guess at some point deep down it has to do
"synchronized", although I haven't checked.
> > I've looked at pages generated by other more efficient JSP compilers
> > (e.g. Resin), and they generally use another approach:
> > Only reuse a tag within a particular page, and don't use a synchronized
> > pool to do it. Just pass the instance around within the generated code.
> > What is important is not primarily the global optimization gained by
> > using pools, but the local optimization gained by not creating tags for
> > each iteration in a iterative custom tag.
> >
>
> Yes reusing a tag handler within a single page will be more efficient
> (for that particular page) but I would guess that once we change to pool
> per thread there's no way newing the tags at each use will be faster
> (at least for a busy site with lots of tags.)
And didn't say you should either. Right now 3.2 new's tags, and it's
slow. I'm saying, do it the middle way, but new'ing it once per page,
and then reuse within that page. No global optimization problems (i.e.
when to grow/shrink the pool), no synch problems, no shared pool
considerations, no hash lookup. All the good stuff and none of the bad.
As I said, last time I checked Resin worked this way, and I think we can
all agree that it's pretty snappy.
> > This is waaaay more efficient, and also avoids the suboptimization of
> > trying to reuse objects using Java code, something which is more
> > efficiently
> > handled by modern JVMs' memory management (i.e. creating objects using
> > "new" is
> > pretty snappy compared with Java-coded pools).
> >
>
> I disagree. I've found that object reuse can be a good performance
> optimization.
Sorry, I should have been more specific. Of course object reuse can be a
good performance optimization. I'm just saying that you gotta balance it
with regard to modern JVM's ability to manage memory and "new" objects.
Optimize locally in code, and let the JVM do it globally. That's just
IMHO though, so feel free to disagree :-)
> > So, please remove the tag pooling, and do it right. If you don't believe
> > me, do some benchmarking or something.
> >
>
> I have done benchmarking and pooling enabled always wins. :) Maybe you
> can send some examples so that we can try and track down the problems.
As above, I've sent code to Costin. But I'll forward it to you to, so
you check it out.
Lastly, I would be absolutely thrilled to find out that the fault was
mine, i.e. some silly coding or config error. :-)
regards,
Rickard
--
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]
