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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
