You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-users@xalan.apache.org by Siljan Simpson <si...@email.com> on 2003/06/27 18:31:07 UTC

usage of DTMManagerDefault

Thanks JoaquĆ­n for the response.

I was going through the code in DTMManagerDefault.java.
DTM getDTM(Source source, boolean unique,
                                 DTMWSFilter whiteSpaceFilter,
                                 boolean incremental, boolean doIndexing)

I was hoping some one could help me understand the benefit of having the incremental and doIndexing flag to true.

Any pointers will be greatly appreciated.

Regards,
Siljan Simpson
-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup


Re: usage of DTMManagerDefault

Posted by Joseph Kesselman <ke...@us.ibm.com>.



>I was hoping some one could help me understand the benefit of having the
>incremental and doIndexing flag to true

These are performance-tuning hints. Not all DTM implementations will
respond to them, or respond the same way to them. But in general:

The incremental flag, when true, indicates that the DTM model should be
built "on demand" rather than being completly constructed in memory before
processing begins. This is basically a latency-versus-throughput issue; if
you're running the stylesheet's output onto a display, for example, this
lets you start producing output as quickly as possible and makes the
application feel more responsive. Incremental mode may also may have
significant advatanges if your stylesheet/xpath doesn't examine the entire
document -- for example, if it only formats chapter 1, there's no reason to
load the other 27 chapters into memory. HOWEVER: Incremental mode does
impose performance costs in some DTMs, so if your main concern is overall
time to style the whole document you may not want to use an incremental
model. See also http://xml.apache.org/xalan-j/dtm.html#settings

Indexing refers to building lookup tables during model construction to help
optimize certain kinds of XPaths -- for example, building a table that
lists all nodes by node name might tremendously speed up evaluation of the
path "//foo". But again, this has trade-offs; the time spent building those
tables isn't always less than the time saved by using them, and the tables
may consume a significant amount of memory. Which tables are built, if any,
and how they are used is up to the specific DTM implementation. Note that
we have not exposed a public control for this parameter at this time; it's
only being used internally, based on our own best guesses about how the
document or RTF is likely to be accessed.


______________________________________
Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
"The world changed profoundly and unpredictably the day Tim Berners Lee
got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk