Re: Performance Question: Expensive Functions in Predi
Hi Eliot, Im interested to know more of how you came to these conclusions while also ignoring the use of xpath within apply-templates/@select to do the bulk of your node selection? I definitely have my own opinions on this but to make sure I wasn't completely off base I did a quick test. To me there are two priorities that need to be accounted for in every program (no matter what language it is written in). These are 1)total cycles to completion and 2)peak memory consumption during the process. There's obviously more than this but to me these are the most important numbers to help predict the overall performance of any application/software solution. If we first look at the total cycles (and define cycles as logic steps within the Trace output) and we take the following three scenarios we get some interesting results. For test XML I used an XML data set with a depth of three(3) child nodes and 96 total elements. A simple boolean test of the xpath revealed that 20 of these nodes matched the statement "foo[@bar = '1']". Scenario One: Xalan 2.5.1: 126 cycles <xsl:apply-templates select="foo[@bar = '1']"/> <xsl:template match="foo"> ... </xsl:template> Scenario Two: Xalan 2.5.1: 199 cycles <xsl:apply-templates select="foo"/> <xsl:template match="foo[@bar = '1']"> ... </xsl:template> <xsl:template match="foo"/> Scenario Three: Xalan 2.5.1: 329 cycles <xsl:apply-templates select="foo"/> <xsl:template match="foo"> <xsl:if test="@bar = '1'"> ... </xsl:if> </xsl:template> All three scenarios output the exact same data. It seems fairly obvious to me where the greatest performance is as far as minimum cycles to complete the transformation is concerened. Actually, scenario one and two use the exact same boolean test that results in the exact same subset of data. The difference in cycles of course comes when you add the fallthrough template that you are refering to which has to be put in place to catch all the elements that don't match the criteria in the match attribute of the template. XSL processors don't like anything that doesn't contain markup so if no match is found the value of the element or attribute gets dumped to the output and the processing continues. While in both cases the select attribute of apply-templates will only pass those elements that pass the boolean test, the first scenarios criteria is refined further than the second and as such the subset of scenario one(which is then matched to its corresponding template) is much smaller than scenario two resulting in fewer nodes to process with the statement contained in the match attribute. In the first two scenarios cycles are saved by reducing the number of elements that are processed as far as possible by using an XPath statement that matches an attribute/value pair in either the @select or the @match attributes of xsl:apply-templates and xsl:template respectively. Scenario three adds one more process to the mix before it begins to break things down (there is an interesting near 1 > 2 > 3 relationship in the total cycles for each scenario) to the attribute/value pair which means theres going to be one more step in every matching element from @select and @match attributes. While I am not suggesting there is no place for the conditional logic elements of xsl I am suggesting that their use should be reserved for fine tuning the results of your transformation and not for processing the bulk of your XPath statements. In fact, IMHO ;) there are very few cases that conditional logic elements should be used to process raw elements and attributes. There best use is when taking the string value of either an element or attribute and processing it further using a combination of conditional logic and string functions. In fact, as a general rule I believe the statement "templates are for processing elements and attributes by matching their values or combinations of values of these elements and attributes while the conditional elements xsl:if and xsl:choose[when][otherwise] should be used to further process the non-XML values of the resulting nodes that have been passed into the template using the above mentioned template match processing." With all of this in mind I see both scenario one and two as necessary methods for bulk transformation of XML data depending one one simple factor: Will the resulting nodeset from the XPath contained in the select attribute of xsl:apply-templates result in elements that will need to be further matched to more than one template? If "yes", use scenario two, and if "no", use scenario one. Actually, this question should be further qualified by asking if the result of the XPath statement can match multiple scenarios but only one of those scenarios needs to be transformed or all of the scenarios need to be transformed exactly the same. If this statement is true then every effort should be made to qualify the elements in the xpath contained in the select attribute and, if necessary, use unions in your match attribute to match multiple elements, element[values], element[@attribute values], or just simply [@attribute values] to the same template to be further processed. Taking peak memory into consideration (I have no data at this point to evaluate so im speculating) it is my speculation that scenario one will cause the smallest peak and scenario 3 the largest. This is based on the simple fact that the further you step into a logic tree the more memory required to store the data that got you in and the necessary data to get you back out. I realize this takes nothing else into account (And there are many more things to consider.) But without data to back me up I don't want to get to deep into speculating anything. I hope that I have in no way caused you to take offense to any of my comments. My intention wasn't to drive down your comments but instead to attempt to qualify with data what is actually taking place inside our transformations. Actual data is the absolute most important thing we can have at our disposal when evaluating performance and I believe that the above numbers, from a general perspective, showcase quite well which solution is best for each particular development scenario. If you have data that suggests anything contrary to what I am saying please let me/all of us know as, like you and everybody else in here, my ultimate goal is to write the best possible code for any given situation. And the more data there is that helps lean our code one way or another the better off we are all going to be in our development efforts. Best regards, <M:D/> ----- Original Message ----- From: "Eliot Kimber" <ekimber@xxxxxxxxxxxxxxxxxxx> To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx> Sent: Wednesday, June 02, 2004 2:10 PM Subject: Re: Performance Question: Expensive Functions in Predicates > >>My question is where, in general, is the best place to use these > >>functions: > >> > >>- In apply-templates specifications? > >> > >>- In match specifications? > >> > >>- As IF blocks within templates? > > I just stumbled onto a subtle (at least to me) difference between these > two nominally equivalent forms: > > <xsl:template match="foo[util:is_applicable()]"> > > and > > <xsl:template match="foo"> > <xsl:if test="util:is_applicable()"> > > > Which is that in the first case all *inapplicable* foo elements fall > through to the default template, which if there's no explicit template > for "foo", means that the content of foo will likely flow to the output, > therefore failing to suppress inapplicable foo elements. Doh! > > Given that, it suggests that putting the check in the match= value is > the least attractive as it requires at least a single separate template > with a lower priority to catch all elements that fail the applicability > check, while doing the check at select time ensures that only applicable > elements will be processed at all. > > Cheers, > > Eliot > -- > W. Eliot Kimber > Professional Services > Innodata Isogen > 9030 Research Blvd, #410 > Austin, TX 78758 > (512) 372-8122 > > eliot@xxxxxxxxxxxxxxxxxxx > www.innodata-isogen.com > > > --+------------------------------------------------------------------ > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list > To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/ > or e-mail: <mailto:xsl-list-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx> > --+-- >
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format