tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Casey Lucas <>
Subject Re: Jasper performance/3.3 tag pooling
Date Wed, 23 May 2001 23:06:39 GMT

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 ahead and try to add the code to the existing jasper.  

When the next gen jasper gets a lot of momentum, we can add the
tag related optimizations to it.

-casey wrote:
> 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-upon overall architecture, of course).
> > NOTE:  For most of the rest of the overall problem (the PageContext
> > implementation, how Jasper fits in with the servlet container, and so
> > on) evolution is probably a very reasonable strategy.  On the compiler,
> > though, I'm not so sure.
> If we are talking about the compiler ( or code generator ): I partially
> agree, the current architecture will get a lot of pressure from more
> complex optimizations or tricks.
> But before we can even start to change the generator we need to do the
> initial refactoring and get the other components in order ( runtime, etc).
> We can also get some optimizations in, and use that to learn what's needed
> from a new generator architecture.
> I just don't think the new generator can happen in a 3.4 space - my goal
> is just to enable an effort to rewrite it, and gather as much information
> as possible about it's requirements.
> In any case - whatever happens in the current generator with regard to
> generated code  will still be usefull for any new generator architecture.
> And if certain optimizations can't be done - that's even better, because
> it would help us understand what's needed.
> I had big hopes for an XSLT based generator, and I still think it may be a
> good way to implement the code generator - and I hope to hear other
> ideas.
> Costin

View raw message