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
