Re: Optimizing and XMLC application

On Wednesday 16 April 2003 14:30, David Corbin wrote:
[ ... snip ... ]
> > 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?>

It'll get parsed 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.

In short: With deferred parsing, the *ML content isn't compiled into the 
generated class anymore. Instead, the *ML file is parsed into a DOM tree at 
the time the corresponding class is first accessed, or whenever the *ML file 
changes. This makes life easier when you're in a situation where your *ML 
pages may change, but you don't want to restart the application.

In order to give adequate performance, the deferred parsing factory doesn't 
parse the page everytime it is accessed but keeps the parsed DOM in a cache 
and generates the individual page instances by cloning this cached template. 
At parse time, the factory also edits the DOM (in exactly the same as the 
XMLC compiler does - rewrite URLs, drop dummy nodes etc.), and this edit 
stage is where you can insert additional actions. The advabtage is that these 
actions are only performed when the page is parsed, but not when a page 
instance is created from the pre-parsed template DOM.

To use deferred parsing:
- compile your pages with the "-for-deferred-parsing" option
- use the XMLCDeferredParsingFactory to load your pages

> > 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.

Hmmm. If you're spending most of the time in the DOMFormatter, it may be worth 
to use the LazyDOM, because the LazyDOM has some optimisations that 
significantly speed up DOM output. 

A bit more detailed: Standard DOM output is quite expensive because the output 
routines have to look at each and every individual character in text nodes 
and attribute values and decide whether it can be output directly in the 
chraacter set that's used in the output stream or needs to be escaped to a 
(named or numerical) entity reference. To optimize this, the LazyDOM keeps 
preformatted text for every DOM node that has not been changed from the 
template (usually the huge majority of the nodes in a given page), so it can 
simply dump these unchanged nodes to the output stream and only needs to do 
the expensive character-by-character examination and escaping on nodes that 
have been changed by the application.

-- 
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

pgpc5UaKtsQgI.pgp
Description: signature