[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Bryan,
At 12:06 PM 7/1/2002, you wrote:
Not very, in that it can be difficult to fathom the mysteries of optimization.
In this case, however, the processor does have to look at every node since each node has to provide the context for the evaluation of the expression(s) in the predicate. I.e. how does it evaluate name()='factorof' without picking up the node whose name it's testing? It would be a pretty smart processor that had already thrown away all the nodes in the wrong position before it did that.
I also confess that my preference for simple clean XPath is as much aesthetic as anything. Yet XSL in general is rife with examples where the elegant and expressive also turns out to be efficient.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
RE: [xsl] XSL: For-Each Efficient or Not?
Subject: RE: [xsl] XSL: For-Each Efficient or Not? From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> Date: Mon, 01 Jul 2002 13:53:33 -0400 |
Bryan,
At 12:06 PM 7/1/2002, you wrote:
Wendell wrote: >m:apply[factorof[not(preceding-sibling::*)]]
>will be better than
>m:apply[child::*[position()=1 and name()='factorof']]
at first I didn't get your point on this one. I supposed on further consideration that it was right, although it seems like it would be mainly dependent on the order in which xpath is evaluated by the processor, I mean that a reasonably clever processor would evaluate [position()=1 and name()='factorof'] first and then from there look for any child::* which matched this, with the result that it would only check the first child to see if it had a name of factorof? Am I very wrong in this supposition?
Not very, in that it can be difficult to fathom the mysteries of optimization.
In this case, however, the processor does have to look at every node since each node has to provide the context for the evaluation of the expression(s) in the predicate. I.e. how does it evaluate name()='factorof' without picking up the node whose name it's testing? It would be a pretty smart processor that had already thrown away all the nodes in the wrong position before it did that.
I also confess that my preference for simple clean XPath is as much aesthetic as anything. Yet XSL in general is rife with examples where the elegant and expressive also turns out to be efficient.
Cheers, Wendell
====================================================================== Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx Mulberry Technologies, Inc. http://www.mulberrytech.com 17 West Jefferson Street Direct Phone: 301/315-9635 Suite 207 Phone: 301/315-9631 Rockville, MD 20850 Fax: 301/315-8285 ---------------------------------------------------------------------- Mulberry Technologies: A Consultancy Specializing in SGML and XML ======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] XSL: For-Each Efficient o, Johannes Döbler | Thread | RE: [xsl] XSL: For-Each Efficient o, Michael Kay |
[xsl] Practicality of Separating Da, intelikon | Date | [xsl] preserve-space, nrashidi |
Month |