>I agree. I spent some time last week looking at possible
>optimizations. The general ideas were:
>
>- pool tag handler objects per application. This could
>still be turned on/off at runtime via module and is
>already available.
>
>- cache (re-use) handlers per page - i.e. only get the handler
>
Hey Mel,
I'll use this as a chance to explain some thoughts
I've recently had on tag pooling. Maybe you and
others have comments.
Mel Martinez wrote:
>
> Hi folks!
>
> I'm still overwhelmed with other priorities (new job,
> house-hunting, moving, etc.) to be able to help again,
> but I manag
Hi folks!
I'm still overwhelmed with other priorities (new job,
house-hunting, moving, etc.) to be able to help again,
but I managed over the last day or so to get caught up
with the list (for the most part - skipped some major
threads along the way).
On tag-pooling: I am +1 on implementing a t
> Thanks for sending the test application. I've been using monthlist.jsp
while
> testing rendered then hand bashed code. After some preliminary bashing :)
> I think it will be possible to call all setters (except runtime
expressions)
> only once per run of the page. Also, we can create / obtain
Rickard,
Thanks for sending the test application. I've been using monthlist.jsp while
testing rendered then hand bashed code. After some preliminary bashing :)
I think it will be possible to call all setters (except runtime expressions)
only once per run of the page. Also, we can create / ob
Hi Costin,
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 23, 2001 10:20 AM
>
> ...
>
> I'm working on a refactoring of jasper, and "easy to read" is a big
> priority. It's moving a bit slower than I expected - now I'm back on
> planning s
[EMAIL PROTECTED] wrote:
> > Jasper performance is a high priority thing for us (nr 1. on our "system
> > performance fixing" list actually), so if possible, absolutely. I can't
> > say I've delved that far into Jasper yet though. It was a bit hard to
> > read.
>
> I'm working on a refactoring of
I think the changes will be too big to add before the 3.3 freeze. I like
your alternative and will start bashing the jsp->java files to get something
optimal before changing the jasper34 generator code. I'll let you know when
I have something that looks interesting so that it can be discussed
b
Casey,
We hope to freeze 3.3 for a release in the next weeks. If you feel the
changes are reasonably small and will not create problems - you can still
do it.
What about:
1. We copy the code from 3.3 as it is in jasper34 area ( except that we
rename the package ).
2. We make sure it builds a
Costin & Craig,
I agree with both of you. The optimizations that Craig mentioned are
exactly the ones that I was hoping to add. Yes, the least fun part
will probably be adding to the existing generator code. But, until a
new generating architecture is in place, I think it would be good to
go
On Wed, 23 May 2001, Craig R. McClanahan wrote:
> I know Costin loves evolutionary change :-), and it's certainly a valid
> approach to Jasper.
>
> But there is also another approach we should consider - a green-field
> recoding of at least some of the major components (conforming to an
> agreed
On Wed, 23 May 2001 [EMAIL PROTECTED] wrote:
> On Wed, 23 May 2001, Casey Lucas wrote:
>
> >
> > btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff?
>
> Difficult question...
>
> The problem with jasper34 is that it doesn't work yet ( the one in
> proposals/jasper34 - I
On Wed, 23 May 2001, Casey Lucas wrote:
>
> btw, If i start tinkering, should I work with jasper34 or the 3.3 stuff?
Difficult question...
The problem with jasper34 is that it doesn't work yet ( the one in
proposals/jasper34 - I still have to move it in the new repository ). Mea
culpa - I trie
On Wed, 23 May 2001, Rickard Öberg wrote:
> Jasper performance is a high priority thing for us (nr 1. on our "system
> performance fixing" list actually), so if possible, absolutely. I can't
> say I've delved that far into Jasper yet though. It was a bit hard to
> read.
I'm working on a refactor
Glenn Nielsen wrote:
[snip]
>
> I just had an idea (dangerous things) regarding tag pooling optimizations.
>
> When Jasper translates a page it should be able to generate information
> about which tag handler classes it needs, and for each tag handler, the
> profile of the attribute/value pa
Glenn Nielsen wrote:
> I just had an idea (dangerous things) regarding tag pooling optimizations.
>
> When Jasper translates a page it should be able to generate information
> about which tag handler classes it needs, and for each tag handler, the
> profile of the attribute/value pairs. At runti
Rickard Öberg wrote:
>
> [EMAIL PROTECTED] wrote:
> > > > 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 is one solution, but what do you do with t
[EMAIL PROTECTED] wrote:
> But in tomcat 3.3 we do a different trick - the thread pool is maintaining
> a "local storage" for each thread, and it's passing it to the worker.
>
> The only synchronization in tomcat is in getting a thread from the thread
> pool - besides that we shouldn't need anyth
[EMAIL PROTECTED] wrote:
> > > 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 is one solution, but what do you do with the pool after page
> > request?
>
>
On Tue, 22 May 2001, Rickard Öberg wrote:
> > 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 sto
On Tue, 22 May 2001, Rickard Öberg wrote:
> Hi!
>
> [EMAIL PROTECTED] wrote:
> > Could you send a small page ( and the taglibs ) and the test conditions ?
>
> I have sent taglib+page and test conditions to Costin.
Thanks, I'll try to add it to the tests dir.
>
> > We know the pool is synchro
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 re
Hi!
[EMAIL PROTECTED] wrote:
> Could you send a small page ( and the taglibs ) and the test conditions ?
I have sent taglib+page and test conditions to Costin.
> 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
Rickard,
Can you please send in some complete examples? Also, did you run the
tests with and without tag pooling enabled on the same version of
tomcat? (By adding removing TagPoolManagerInterceptor.)
My experience has been that if the jsp uses many tags, then pooling is
a big performance gain
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 witho
25 matches
Mail list logo
