tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Jasper performance
Date Wed, 16 May 2001 08:11:04 GMT
On Tue, 15 May 2001, Jon Stevens wrote:

> Currently Jasper output's Java code from within Java code. This is about as
> fast as you are going to get because there is no intermediate transformation
> step going on, just conditional output of String data entirely within Java.
> While this is very fast, it also means that modifications to Jasper are damn
> near impossible without reading the source code in a fair amount of detail
> and doing quite a lot of testing.

We do need to read source code and do testing in order to make
modification in a code generator ???  :-)...

XLST will not change that.

> Now, people are suggesting using something like XSLT to transform the .jsp
> XML/XHTML file into a .java file. Because you are introducing the XSLT layer
> into things, that will have a negative impact on the transformation
> performance (I'm not certain how much, but I am pretty much certain it will
> be more than the current system.). Given that this only happens when you are
> in development mode, I think that people developing JSP pages might not like
> the performance hit.

The code generation stage is not significant - compared with the javac
compilation. Some people are even using XSLT at runtime ( not that this is
a good idea ) - so I doubt it'll have such a significant impact on
development mode ( if it's ok for a runtime page, it should be ok for a
developer ).

In addition, for "pure" jsp ( if no java fragment is used ) it would be
possible to use the same technique as XSLTC ( now part of xalan ) - and
generate the bytecode directly ( since most of the generated code is
"glue" ) - and avoid the javac. 

Of course, the big goal is to allow some taglib optimzations ( create
alternate implementations for common-used tags, with same behavior but
generating code directly ) - and that's why XSLT is need.

The good news about JSP is that it is a specification. People can use
a different implementation if they are not happy with one, or use one for
development and one for deployment. 

( I have a feeling Cocoon2 and Resin are both using XSLT in developing the
pages - so I guess we will be safe, both are doing OK )


View raw message