xsl-list
[Top] [All Lists]

Re: Performance Question: Expensive Functions in Predicates

2004-05-28 07:27:14
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