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
pgpmb8mxrMYcx.pgp
Description: signature
|
