Niclas Hedhman wrote:
On Thursday 27 May 2004 23:35, Eliot Kimber wrote:
I have a general question about predicting performance in the general
case. I know that the best answer is "try it and see" but I'm wondering
if there's a general principle that can guide design in this particular
case.
If "applicability" are extensive checks, the work load is high and
"non-applicable" results in node reduction, I have found it more efficient
and not too complicated to create a parsing filter instead, prior to the XSLT
processing.
That's an interesting idea. I hadn't considered it, partly because I
just don't normally do SAX-based stuff because optimal performance has
not been a top requirement in the work I've done lately (and as a matter
of engineering practice I only address performance issues once the core
business logic is sound and proven as long as performance is otherwise
acceptable) and partly because I try to keep the number of distinct
system components as small as possible, so I prefer to do everything in
XSLT if I can just to limit potential points of failure and overall
system complexity. But that can have the side effect of making the XSLT
more complex, as is the case here. So from an engineering activity it's
a question of finding the right balance between system complexity,
processing performance, and code maintainability (which normally means
simplicity at the template/method level). Obviously there can be no
right answer in general, so it's important to understand what cost and
benefit one can expect from a particular coding approach.
I can see that for performance, and for keeping the XSLT simpler and
easier to maintain, that a separate SAX filter could work well. My main
concern there would be the complexity of implementing the business logic
as a SAX event handler. In many cases the check is purely hierarchical
or, in the simplest case, requires examining only the current element,
but in some cases we have the check involves examining siblings,
descendants, or worse (e.g., nearest preceding element of type foo with
a descendant of type bar that is itself applicable--relatively easy to
do in XSLT, not so much in a streaming SAX application).
And now that you mention it I can see that a SAX filter might be a good
way to implement XInclude resolution, although I've already got it
implemented in XSLT as a standalone step. But a SAX processor would be
more generally applicable (I could use it for DOM construction, for
example). Hmm.
Cheers,
E.
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9030 Research Blvd, #410
Austin, TX 78758
(512) 372-8122
eliot(_at_)innodata-isogen(_dot_)com
www.innodata-isogen.com