tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luis Neves <lne...@netcabo.pt>
Subject Re: Charsets/Encoding
Date Tue, 03 Jun 2003 17:19:21 GMT
On Monday 02 June 2003 13:38, Mind Bridge wrote:



> 	Having the response charset clearly defined in the page/component/app/etc
> carries certain benefits as well. The most important of which is
> performance. According to the profiling done by Luis Neves, Tapestry is
> greatly delayed due to the constant char -> byte conversion when generating
> the response (mostly in PrintWriter). Knowing the charset ahead of time
> would allow doing the conversion for the static text (template) at page
> load and greatly improve the performance.

I think the problem is not so much the "char -> byte conversion" (although it 
would be cool if this could be avoided) but the great number of times this 
conversion is done due to Tapestry use of recursion.
One of this days I was reading the API of a sourceforge project called xmlenc 
(<http://xmlenc.sourceforge.net/>) who's claim to fame is to be "the fastest 
XML output library for Java", if this is true or not is left as an 
exercise... anyway on the javadocs it says this:

Performance hints
It is usually a good idea to let XMLOutputter instances write to buffered 
Writers. This typically improves performance on large documents or relatively 
slow or blocking output streams.

Instances of this class can be cached in a pool to reduce object creations. 
Call reset() (with no arguments) when storing an instance in the pool. Use 
reset(Writer,String) (with 2 arguments) to re-initialize the instance after 
fetching it from the pool.

Maybe Tapestry could also benefit from a similar approach of caching the 
"writers"... or maybe not... the bowels of Tapestry are mystery to me.

> 	Is there a reason NOT to do these things?

I can't think of any, and your ideas seem sound, but then again my opinion 
doesn't carry much weight.

Best regards,
Luis Neves

View raw message