[
http://jira.codehaus.org/browse/JAXEN-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=196666#action_196666 ]
Brian Ewins commented on JAXEN-88:
----------------------------------
Not entirely. JAXEN-31 helps if the user avoids using last() (for example) since we don't have to touch all the nodes. My comment above is that this optimisation is one of family of transformations like these:
count(x) < y is equivalent to: for (node in x) { count++; if (!(count < y)) {return false} } return true;
and
count(x) == y is equivalent to: for (node in x) { count++; if (count > y) {return false} } return count == y;
These loops terminate early without hitting every node in x. There's no way for the user to express this intent in xpath, unless we add some extension functions:
count(x) < y is equivalent to: count-between(x, 0, y - 1)
count(x) == y is equivalent to: count-between(x, y, y)
Where count-between(x, ymin, ymax) is defined as:
for (node in x) { count++; if (count > ymax) {return false} } return count >= ymin;
...once we have these, we can get the optimisation by transforming the parse tree to use these functions wherever theres a count() comparison. Even after JAXEN-31 lands, this is still a win.
Re the bug title, 'early termination with positional predicates'... we /may/ have that one covered. There are still some internal uses of size() in jaxen, I'd have to check.
> Early termination with positional predicates
> --------------------------------------------
>
> Key: JAXEN-88
> URL:
http://jira.codehaus.org/browse/JAXEN-88> Project: jaxen
> Issue Type: Improvement
> Components: core
> Reporter: Elliotte Rusty Harold
> Fix For: 2.0
>
>
> Michael Kay describes a Saxon optimization in this article on developerWorks:
>
http://www-106.ibm.com/developerworks/library/x-xslt2/> "A predicate such as para[position() <= 3] selects the first three <para> children of the current node. It is not necessary to apply this predicate explicitly to every <para> element to see if it is true, since processing can stop after the third node."
> As always with this sort of stuff, we need to carefully benchmark to insure we don't spend more time doing the optimization than it actually saves.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
