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 I do this, will it be treat the snipet is one large block, or does it
get parsed out into DOM nodes?>
> 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.
>

Can you elborate on this, or point me to an example/documentation.  I'm
not at all familiar with how this features works.
> 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.

I'm taking over 2 seconds just in DOMFormatter.toString(), which is now
about almost 20% of my page request.  So, Anything I can do to "compress"
reduce the count of DOM Objects, will probably help.
>> 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.

I have tried OptimizeIt, and to me it's just "OK".  I recovered 10 useless
seconds using it (and my brain), with one fix (about 40% of my worst page
request).  I just can envision tools that are a) much easier to use, and
b) let you look at data in a lot more ways than they currently do.
>
> --
> 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, [email protected]