Re: Optimizing and XMLC application

On Tuesday 15 April 2003 20:39, David Corbin wrote:
> I have an XMLC-based application that needs some optimiztion.  It is XHTML
> based (which, I think means it cannot use the LazyDOM, right?).
> Even so, the primary page I need to optimize (at this point) duplicates
> and populates a block of about 8-10 elements.  The problem is when we do
> that 300 times, on one page we get a little slow. I'm looking for
> optimzation tips.  Small localized optimizations are most desired, but
> I'll certainly consider larger-scale ones (see below).  Here are some that
> have occurred to me:
> 1) Eliminate all the "white-space-text nodes" that are not really
> necessary in the duplicated "row" template2) Consider converting to HTML
> and using LazyDOM (will this really help me if I'm mostly creating new
> nodes?3) Pre-generate large chunks of the final DOM (a good majority of the
> duplicated "rows" are from domain data, and fairly static).4) Pre-generate
> the data has HTML at run-time, or even at compile time (see #3 above)

All of these can be a big win. If you're able to pregenerate HTML at compile 
time, I'd suggest you generate a HTML snippet, and include it into the 
generated page using SSI include syntax (yes, XMLC does SSI :-) That way, you 
can combine the advantages of generating HTML with having a full, parsed DOM.

If you can't pregenerate the data at compile time but it's nonetheless pretty 
static, it could be worth using the new XMLC 2.2 with deferred parsing and 
include the data in the page template, at parse time. That way, you only need 
to assemble the data once when that page is loaded (or when the template is 
phased out of the page cache), and not every time the page is requested.

It's a bit tricky do do this (you need to write your own XMLCFactory), but 
I've had a huge success with this in a situation where including 
mostly-static data made a huge performance hit - although in my case, it 
wasn't as much data as in yours, the data was just pretty expensive to get.

> P.S.  I am doing profiling and looking for "hot spots", but as near as I
> can tell (it's still early) there are no GOOD java profilers.

Did you try OptimizeIt? I've found it to be pretty good for profiling CPU 
usage, and not that bad for profiling memory usage either.

-- 
Richard Kunze 

[ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
http://www.tivano.de, kunze@xxxxxxxxx

pgpCdSwFrzG6K.pgp
Description: signature