JSPInterceptor Performance

[Adam Myatt <my...@potsdam.edu>]

Hi,

I have a quick question that hopefully someone can answer.

I was reading the DOCs about JspInterceptor in server.xml and came upon
[what I thought] was a great concept. Setting the "largeFile" option to
true extracts the HTML and puts it in a separate .dat file. I thought this
was great since it made the .java's created smaller and in turn the
compiled class files smaller. After examining the code though, I see to do
this, it uses a char[][] called "_jspx_html_data". I'm assuming this is bad
since using such a data structure residing in memory would hinder
performance, especially if more than several files are doing so (and with
many simultaneous users as well).

 Does this indeed cause worse performance (as opposed to leaving
"largeFile=false" and therefore the HTML as out.print statements in the
class) or does the JVM garbage collector handle the cleanup after the
compiled JSP page is output to the browser? I would appreciate it if
someone could clear this up and perhaps give me any ideas/info on real
pros/cons to doing it either way. Many thanks.

 - Adam

------------------
Tomcat 3.3
JDK: Sun Java 1.3.1
System: Wink2k SP2
-------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: JSPInterceptor Performance

[co...@covalent.net]

On Thu, 7 Mar 2002, Adam Myatt wrote:

> was great since it made the .java's created smaller and in turn the
> compiled class files smaller. After examining the code though, I see to do
> this, it uses a char[][] called "_jspx_html_data". I'm assuming this is bad
> since using such a data structure residing in memory would hinder
> performance, especially if more than several files are doing so (and with
> many simultaneous users as well).

Without largefile the data will be in some static strings ( or char[] ) -
it's exaclty the same overhead.

Except that with largefile you can support strings > 64k ( a limitation
of the .class format ). 

Right now we don't do anything special about the data,
but that should be easy to add - i.e. have a central object
managing the chunks and expiring those not used recently. 


>  Does this indeed cause worse performance (as opposed to leaving
> "largeFile=false" and therefore the HTML as out.print statements in the
> class) or does the JVM garbage collector handle the cleanup after the
> compiled JSP page is output to the browser? I would appreciate it if
> someone could clear this up and perhaps give me any ideas/info on real
> pros/cons to doing it either way. Many thanks.

largeFile will be a bit slower for the first access ( since 2 files 
are read instead of one ). It is required to support large jsp pages
( the out.println() solution will just not work ), and it has 
has a huge potential for optimizations. Most of it unexploited.


Costin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>