Costin,

sounds good.

btw, when do you think the generator code in 34 will settle down
a little?

-casey

[EMAIL PROTECTED] wrote:
> 
> Ok, time to discuss the first mini-optimization.
> 
> Right now jasper has 2 ways to output data - one is the common
> out.println("String ");
> 
> The other ( not very used ) is using an additional file to store the
> strings, and it's enabled by "largefile" option.
> 
> The output system is probably the most important part of jasper ( except
> taglibs ) with regard to performance.
> 
> My proposal is to drop the first option, which is also failing for chunks
> bigger than 64k ( due to .class file limitations on constant pool
> strings), and use the second ( with some changes ) in all cases.
> 
> The main problem is that the java file will be less readable (
> out.println( strings[4] ) instead of the real string ). That can be
> resolved easily by generating a comment with the real string ( most users
> will not read the java file - now that we are close to line number
> mapping it'll happen even less ).
> 
> Note that this is nothing new for jasper - the option has been present in
> jasper and is tested.
> 
> The main benefits:
> 
> - full control over static content allocation. If the strings are part of
> the constant pool, they are loaded with the class and garbage collected
> only if the class itself is gc. By loading them from the file we could
> easily add a LRU cache for the static chunks and reduce the runtime memory
> usage quite significantly.
> 
> - ability for containers to control the static content. For a large file
> the connector could send only the file and offsets to apache, instead of
> reading and sending the large chunk.
> 
> - it will work with large files without requiring users to set options
> ( that could be resolved by detecting large chunks and turning it on
> automatically )
> 
> - a single output model - easier to test and optimize than 2.
> 
> Let me know if you see any problem with that - it'll probably happen next
> week, I'm still stuck with the JspServlet.
> 
> Costin
>

Reply via email to