On Fri, 22 Mar 2002, peter lin wrote:

> I've been doing benchmarks with JSTL on some dynamic pages and noticed
> under medium & heavy load 4-64 concurrent connections, the performance
> degrades rapidly.  I looked at ExpressionEvaluatorManager and it looks
> like it doesn't create a pool of parsers. I posted some benchmarks on
> tomcat user mailing list
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg48946.html
> 
> It might be beneficial to recyle the parsers. this way it would reduce
> memory usage and gc. The reason I say is because I am witnessing heavy
> disk caching with 4+ concurrent connections. These problems might be
> solved by adding 1gig of memory, but that would only be a temporary
> fix, especially for systems that can only support 2gigs of ram.

Interesting thought, Peter.

Given that instantiating an Evaluator object involves no specific logic on
construction, the only cost of not having a pool is that of object
creation itself, which should be exceptionally well optimized under any
JIT.  As a general rule, I strongly hesitate to pool objects unless
there's a demonstrated reason it'll help.  (Most products pool objects WAY
too much, which leads to unnecessary complexity and -- indeed -- potential
performance problems.)  The performance you're experiencing doesn't sound
too good, but do you have any reason to think that the logic within
ExpressionEvaluatorManager (in particular) is to blame?

The evaluator keeps a static cache of values, so literally the only
benefit of pooling our interpreter instances would be to save the
instantiation itself, which should take about ten low-level instructions
on a modern JIT.  (That is, the evaluator has an empty constructor, and
all its work is done on the stack -- with the aid of a few static caches.)

Thanks very much for the suggestion, though; I'd be curious if you have
any data that does implicate one part of the JSTL RI over another.

-- 
Shawn Bayern
Author, "JSP Standard Tag Library"  http://www.jstlbook.com
(coming this summer from Manning Publications)


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to