Hi Rickard,
Could you send a small page ( and the taglibs ) and the test conditions ?
Most tests I run show a (significant) improvement in performance.
We know the pool is synchronized and that may create problems under heavy
load, and we know how to fix this ( by using a per/thread pool without
synchronization ).
That was planned for later, in jasper34 space - but if you send code that
shows a significant degradation in performance in some reasonable
situations we can still fix it in 3.3.
Regarding the default - I think it should be enabled, mostly because that
will require people to make sure their taglibs are working corectly in a
pooled environment. It should be possible to disable it on a per
application basis, and we need to make sure we document how to do that.
I don't think the design is bad - just the implementation of the pool, but
this is the first attempt with the goal of making sure the pooling work,
optimizations will come later. The current experience with tomcat
performance evolution from 3.1 to 3.3 shows that recycling objects has a
huge effect ( if implemented corectly ) - and I see no reason why jasper
would be different. I'm looking forward to the VM where the allocation and
GC will be free ( so far most do synchronize on object allocation ).
Costin
On Mon, 21 May 2001, Rickard Öberg wrote:
> Hi!
>
> Ok, so now I've tested the Jasper performance with the 3.3 tag pooling
> fix. The test was performed with a medium complexity page using lots of
> iterative custom tags in a hierarchical fashion (i.e. tags within tags).
>
> Results:
> The page ran slower, and above all the response time varied greatly
> (between 250ms and 460ms, whereas without tag pooling we got between
> 230ms and 340ms).
>
> Looking at the generated code, I'm not particularly surprised: it uses
> (it seems) a real shared tag pool, so using tags will execute code that
> needs
> to be synchronized.
>
> 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".
>
> 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.
>
> 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).
>
> So, please remove the tag pooling, and do it right. If you don't believe
> me, do some benchmarking or something.
>
> /Rickard
>
>
