Nabble - codehaus - Jaxen

[jira] Updated: (JAXEN-149) Upgrade to Maven 2

2009-11-05T06:01:55Z

[ http://jira.codehaus.org/browse/JAXEN-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksander Adamowski updated JAXEN-149:
---------------------------------------

Attachment: 0001-Specified-groupId-and-version-for-reporting-plugins.patch

Brian, in my environment the site build (actually site:stage) would fail unless I'd specify the groupIds and stable versions of relevant plugins.

Have a look at attached patch. With those changes applied, jaxen.codehaus.org site gets built properly on my machine in target/staging/jaxen.codehaus.org/home/projects/jaxen/public_html/.

One should specify plugin versions anyway, to make the build repeatable. Also, specifying groupId is a good practice as it sometimes creates problems in resolving plugin dependencies (the site is notorious for that).

> Upgrade to Maven 2
> ------------------
>
> Key: JAXEN-149
> URL: http://jira.codehaus.org/browse/JAXEN-149
> Project: jaxen
> Issue Type: Task
> Components: Build
> Affects Versions: 1.1
> Reporter: Elliotte Rusty Harold
> Fix For: 1.1.3
>
> Attachments: 0001-maven-2-build-support.patch, 0001-Specified-groupId-and-version-for-reporting-plugins.patch, jaxen-maven2-upgrade.patch, mvn.patch, pom.xml
>
>
> One of these days we should move forward to Maven 2, but not for Jaxen 1.1.

--
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

From forum: jaxen - dev

[jira] Commented: (JAXEN-88) Early termination with positional predicates

2009-10-30T07:38:26Z

[ 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.

From forum: jaxen - dev

[jira] Commented: (JAXEN-88) Early termination with positional predicates

2009-10-30T06:41:26Z

[ http://jira.codehaus.org/browse/JAXEN-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=196655#action_196655 ]

Aleksander Adamowski commented on JAXEN-88:
-------------------------------------------

Hasn't JAXEN-31 addressed this?

From forum: jaxen - dev

[jira] Updated: (JAXEN-149) Upgrade to Maven 2

2009-10-26T12:22:27Z

[ http://jira.codehaus.org/browse/JAXEN-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Ewins updated JAXEN-149:
------------------------------

Attachment: 0001-maven-2-build-support.patch

Some things were still not working correctly, as all the xdoc and resources needed to be moved to work with the new site plugin; also the old navigation.xml doesn't work any more, so I crafted a new site.xml. This patch can't be applied with svn - it will apply to the master branch of the git repo attached in jaxen-31. (I don't know how to get git to produce svn-compatible patches when there's binary stuff involved - in this case the jaxen logo moved). Stylistically, this appears to be pretty much what we have on the website, except the legend is gone from the bottom of the left hand menu - there doesn't seem to be a way to get that any more.

Also, the checkstyle report had 14000+ errors in it, which wasn't believable. I've added a checkstyle.xml which I believe covers what we used to do in the project.properties, but it still reports 4000+ errors - checkstyle has gained a lot of checks since the version we used.

> Upgrade to Maven 2
> ------------------
>
> Key: JAXEN-149
> URL: http://jira.codehaus.org/browse/JAXEN-149
> Project: jaxen
> Issue Type: Task
> Components: Build
> Affects Versions: 1.1
> Reporter: Elliotte Rusty Harold
> Fix For: 1.1.3
>
> Attachments: 0001-maven-2-build-support.patch, jaxen-maven2-upgrade.patch, mvn.patch, pom.xml
>
>
> One of these days we should move forward to Maven 2, but not for Jaxen 1.1.

From forum: jaxen - dev

[jira] Updated: (JAXEN-149) Upgrade to Maven 2

2009-10-26T07:53:26Z

[ http://jira.codehaus.org/browse/JAXEN-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Ewins updated JAXEN-149:
------------------------------

Attachment: mvn.patch

Attached an updated version of the patch for testing. The previous version wasn't quite correct:
* the jdom, dom4j, xom dependencies should be optional (see JAXEN-138)
* the xmlapis/xerces dependencies should be 'provided' (later JREs have these, don't need to impose old xerces version)
* 'mvn site' didn't work due to missing/misconfigured plugins
* the linkcheck plugin doesn't exist in m2. (Unfortunately - running it from maven 1 shows we have a bunch of broken links)
* the issue reporting system needs specified - its JIRA (otherwise reports fail looking for TRAC)
* the changes plugin needs a commons-codec dependency. At least, on one of my machines it did. This is apparently intermittently reported for that plugin and always ends up being fixed by adding an external dependency.
* added the assembly plugin, and src-assembly.xml, to simulate the additional artifacts our old maven.xml was creating for 'maven dist'. I /presume/ these are the things we offered for download from sourceforge - is this still necessary? Use "mvn assembly:assembly" to generate these artifacts (XXX-bin.tar.gz, XXX-bin.zip, XXX-src.tar.gz, and XXX-src.zip)
* fixed a bug that the assembly plugin creates archives containing the full path to your files by depending on an explicit version of this plugin.
* javadoc plugin was misconfigured, leading to unrecognized '@todo' (the tags configuration block needs to be in the reporting section)
* source file encoding needs specified to suppress a lot of warning messages in report generation.

Building like this was surprisingly flaky. I tried with IDEA 8.1 (win32), mvn directly (win32, OS X), and Eclipse Ganymede (OS X). Each environment complained slightly differently about missing dependencies.

Hence, I don't think this is ready to land just yet, but worth trying out.

> Upgrade to Maven 2
> ------------------
>
> Key: JAXEN-149
> URL: http://jira.codehaus.org/browse/JAXEN-149
> Project: jaxen
> Issue Type: Task
> Components: Build
> Affects Versions: 1.1
> Reporter: Elliotte Rusty Harold
> Fix For: 1.1.3
>
> Attachments: jaxen-maven2-upgrade.patch, mvn.patch, pom.xml
>
>
> One of these days we should move forward to Maven 2, but not for Jaxen 1.1.

From forum: jaxen - dev

Re: Fwd: Jaxen performance test results

2009-10-24T15:00:00Z

On Wed, Oct 21, 2009 at 9:52 AM, Baz <brian.ewins@...> wrote:

> ^ since this code iterates over all returned nodes, it forces full
> evaluation of the nodeset, ie it will always be as slow as possible.
> The benchmark doesn't force full evaluation, so will penalize this
> implementation versus the various JAXP engines tested. It doesn't
> include tests like 'boolean(/x/y/z/)' - which would be fast - since
> the Node.query() api doesn't support that kind of xpath.

In CVS I have eliminated the iteration you noted in XOM. However I did
this by combining it with another iteration in JaxenConnector you
didn't notice so the effect is likely small at best, and doesn't stop
the loading of the list. However one pass through the list is still
likely better than two.

I'm not sure I can really fix this because XOM needs to update the
list returned to take account of differences between XPath's/Jaxen's
data model and XOM's.

Practically I suspect the real performance win for XOM would be
caching the compiled XPath expressions.

--
Elliotte Rusty Harold
elharo@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: jaxen - dev

[jira] Commented: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-23T15:41:27Z

[ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195774#action_195774 ]

Aleksander Adamowski commented on JAXEN-31:
-------------------------------------------

BTW, I've already started to adapt jBPM-BPEL to take advantage of Jaxen LazyLists:

https://jira.jboss.org/jira/browse/BPEL-313

> if jaxen stopped using lists it would be 37x faster
> ---------------------------------------------------
>
> Key: JAXEN-31
> URL: http://jira.codehaus.org/browse/JAXEN-31
> Project: jaxen
> Issue Type: Improvement
> Affects Versions: 1.0
> Reporter: Brian Ewins
> Fix For: 2.0
>
> Attachments: Brian_Ewins_JAXEN-31_perf.patch, jaxen.zip, perf.patch, perf.patch, perf.patch, stuff.tgz
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> The short story - I've rewritten jaxen to use a nodeset abstraction instead of a list to accumulate results. With the unit tests at nearly 100%, the performance test on dom4j runs in ~200ms on my 1GHz powerbook, compared to ~7400ms for the nightly jaxen build. The failing unit tests are for paths not covered in the performance test.
> The long story - I wrote an implementation of the draft ISO Schematron spec on top of Jaxen, instead of the more usual XSLT. The schematron spec is designed so this can be done, mainly for performance reasons. Once I had enough working I was able to compare jaxen with xalan on the 'screamatron' torture test, which is using schematron to validate the schematron 1.5 spec. I was suprised to find that jaxen was about 2x /slower/ than xalan, and marginally slower with a jdom navigator than a dom4j navigator. Looking at why it was so slow, it became clear that the problem was that throughout jaxen it's building lists of intermediate results to filter down, instead of generating the 'next' result on demand. There's comments about this in several places in the code, but the list thing is so ingrained it needs more than a little refactoring to fix.
> I decided to have a go. This change produces apis incompatible with previous versions of jaxen, so this will be a lump of code not a wee patch. I've basically cloned jaxen to 'org.jaxen2' to work on it. I'm nearly done with the changes, failing tests for the non-xpath extension functions which I havent implemented yet, patterns (not touched at all yet), and a couple of minor bugs.
> I'll post the code on jira once I'm done, but here's the gist of the changes I made:
> - Introduce a Nodeset abstraction instead of a list...
> public interface extends Iterator {
> Object current();
> int position();
> // use of last() replaces the internal iterator with an iterator over a list caching results.
> // it's basically a fallback on what jaxen used to do.
> int last();
> }
> the reason for this is obvious, eg you can just test 'hasNext()' to check the boolean value of a nodeset.
> - change the signature of Expr to allow the selection of a fast code path
> public interface Expr {
> // these require context because of variable/function refs only. see later.
> boolean isBoolean(Context ctx);
> boolean isNumber(Context ctx);
> boolean isString(Context ctx);
> boolean isNodeset(Context ctx);
> boolean booleanValue(Context ctx);
> double numberValue(Context ctx);
> String stringValue(Context ctx);
> Nodeset nodesetValue(Context ctx);
> // etc
> }
> this is really for my own sanity as there's so much code to maintain. Throughout jaxen, everything is untyped, so its fairly easy to (eg) pass a nodeSet when you meant to pass a node; there's instanceof checks, == null checks, and casts everywhere to deal with this. Once you put everything behind an interface like the one above, making objects responsible for their own casts, a lot of the code is simplified, eg addition is just expr1.numberValue(ctx) + expr2.numberValue(ctx). All but a couple of classes inherit from abstract base classes that implement all but one of those methods (eg StringExprBase leaves stringValue() abstract.)
> Variable/Function refs don't have a type without context in my version, and like Jaxen I look up functions, variables every time. This isn't smart - in xpath we can resolve all variable, function refs beforehand, and get faster code as a result. I'll probably change things so I have 'bound' and 'unbound' exprs, add 'BoundExpr bind(VariableContext,FunctionContext)'. I'll still need to pass these as members of Context to support the 'evaluate' extension function though.
> Another approach to the same concern that I didn't try is to pass in a typed context, eg 'StringContext', 'NodesetContext', etc (think of this as allowing things like perl's 'wantarray()'. That approach would make it easier to expand the number of supported types (eg for xpath2) in future, I'll try it once the tests pass.
> - moved all the functions to a single utility class
> public class Functions {
> String substring(String s, double start, double end);
> // etc
> }
> this makes it easier to unit test the xpath functions, since they are mostly context-independent. Functions that need a navigator get it passed as the first arg, functions that optionally use the context node instead of an argument have that function added as a method of Context. Incidentally I changed some of the unit tests to get mine to pass - in particular I changed the substring() tests back to match the spec (they don't currently).
> No function in my version returns null. (compare to eg the name, namespaceuri functions of Navigator). The xpath spec uses "" or an empty nodeset throughout, so do I, this gets rid of a lot of == null checks.
> Some of the bugs against the current version of jaxen are fixed by this code - eg the use of double throughout allows gt/lt comparisons of longs (bug jaxen-28), + both of the bugs I filed previously.
> I'd estimate I can finish this in the next week.

From forum: jaxen - dev

[jira] Resolved: (JAXEN-205) Accidental subtree copy on the SVN trunk?

2009-10-22T11:27:27Z

[ http://jira.codehaus.org/browse/JAXEN-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Elliotte Rusty Harold resolved JAXEN-205.
-----------------------------------------

Resolution: Fixed
Fix Version/s: 1.1.3
Assignee: Elliotte Rusty Harold

I believe I have fixed this now.

FYI, I used SVN from a computer where I have not installed my ssh keys using just my username and password, so foliks who think they're locked out may want to try again if they still remember their CVS credentials.

> Accidental subtree copy on the SVN trunk?
> -----------------------------------------
>
> Key: JAXEN-205
> URL: http://jira.codehaus.org/browse/JAXEN-205
> Project: jaxen
> Issue Type: Task
> Components: Build
> Reporter: Aleksander Adamowski
> Assignee: Elliotte Rusty Harold
> Fix For: 1.1.3
>
>
> In the SVN repository, one can see that the Jaxen sources are duplicated inside themselves on the trunk:
> https://svn.codehaus.org/jaxen/trunk/jaxen/
> https://svn.codehaus.org/jaxen/trunk/jaxen/jaxen/
> This doesn't look like an intentional SVN branch and doesn't seem to make any sense.
> If they are indeed accidental, I suggest deleting them as they make diffs between tags/branches and the trunk very cumbersome (not to speak about GIT repositories of other developers).

From forum: jaxen - dev

Re: Fwd: Jaxen performance test results

2009-10-22T04:52:17Z

On Wed, Oct 21, 2009 at 9:52 AM, Baz <brian.ewins@...> wrote:

> Internally the benchmark uses xom's Node.query() to get back a list of
> nodes, rather than calling jaxen directly (the code is here:
> https://bosshog.lbl.gov/repos/java-u3/tags/v1_1/nux/src/nux/xom/tests/XQueryBenchmark.java
> ). So I took a look at what Node does, excerpting the relevant bits:
>
> JaxenConnector connector = new JaxenConnector(xpath);
> // ...
> List queryResults = connector.selectNodes(this);
> Iterator iterator = queryResults.iterator();
> while (iterator.hasNext()) {
> Object o = iterator.next()
> // ...

Actually the relevant bit may be even higher up the call chain. This
has already happened by the time you get to the code you noticed:

public List selectNodes(Object expression) throws JaxenException {

List result = super.selectNodes(expression);
// Text objects are returned wrapped in a List.
// We need to unwrap them here.
ListIterator iterator = result.listIterator();
while (iterator.hasNext()) {
Object next = iterator.next();
if (next instanceof List) {
List list = (List) next;
// replace the list with the first item in the list
iterator.set(list.get(0));
// insert any subsequent Text objects into the list
if (list.size() > 1) {
Iterator texts = list.listIterator(1);
while (texts.hasNext()) {
iterator.add(texts.next());
}
}
}
}
return result;

}

So I'm iterating through the list twice. If nothing else, I suspect I
can get that down to a single iteration. However I'm not sure I can
eliminate the iteration completely.

--
Elliotte Rusty Harold
elharo@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: jaxen - dev

Re: Fwd: Jaxen performance test results

2009-10-22T04:48:25Z

On Wed, Oct 21, 2009 at 9:52 AM, Baz <brian.ewins@...> wrote:

There might be some things I can do to optimize that path and avoid
early loading, but nothing too easy or obvious. For jaxen's own
purposes I would suggest a benchmark based purely on DOM.

--
Elliotte Rusty Harold
elharo@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: jaxen - dev

[jira] Commented: (JAXEN-206) bad order when context is a list of nodes at different depths

2009-10-22T04:30:26Z

[ http://jira.codehaus.org/browse/JAXEN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195562#action_195562 ]

Elliotte Rusty Harold commented on JAXEN-206:
---------------------------------------------

I've committed this patch and verified that I still have SVN access. Please verify that everything seems fine, and then close this bug. Thanks.

> bad order when context is a list of nodes at different depths
> -------------------------------------------------------------
>
> Key: JAXEN-206
> URL: http://jira.codehaus.org/browse/JAXEN-206
> Project: jaxen
> Issue Type: Bug
> Components: core
> Affects Versions: 1.1.3
> Reporter: Brian Ewins
> Attachments: mismatch.patch
>
>
> As described by Elliotte on the list:
> Consider this:
> <z>
> <a>
> 
> </a>
> <c/>
> </z>
> Suppose the list includes b and c in document order. c's parent
> precedes b's parent even though b precedes c
> When calling xpath.selectNodes(context) we can supply a list of nodes instead of a single node. By supplying a list containing b and c as described above, and selecting "parent::*", we should get the list [z, a] returned. Instead we get [a, z]. The reason is that DefaultLocationPath does not sort the nodes into document order when there is only a single step in the location path.
> Patch attached, including test case.

From forum: jaxen - dev

Fwd: Jaxen performance test results

2009-10-21T06:52:15Z

Hoping these attachments make it through... Aleksander sent me these
benchmarks made using the nux XQueryBenchmark script. The jaxen-31
lazy-loading came out consistently worse, even on paths where it
should have performed better. For some paths this is expected due to
the additional overhead, but it shouldn't have been worse for all so I
took a look.

Internally the benchmark uses xom's Node.query() to get back a list of
nodes, rather than calling jaxen directly (the code is here:
https://bosshog.lbl.gov/repos/java-u3/tags/v1_1/nux/src/nux/xom/tests/XQueryBenchmark.java
). So I took a look at what Node does, excerpting the relevant bits:

JaxenConnector connector = new JaxenConnector(xpath);
// ...
List queryResults = connector.selectNodes(this);
Iterator iterator = queryResults.iterator();
while (iterator.hasNext()) {
Object o = iterator.next()
// ...
}

^ since this code iterates over all returned nodes, it forces full
evaluation of the nodeset, ie it will always be as slow as possible.
The benchmark doesn't force full evaluation, so will penalize this
implementation versus the various JAXP engines tested. It doesn't
include tests like 'boolean(/x/y/z/)' - which would be fast - since
the Node.query() api doesn't support that kind of xpath.

-Baz

---------- Forwarded message ----------
From: Aleksander Adamowski <aleksander.adamowski@...>
Date: 2009/10/21
Subject: Jaxen performance test results
To: Brian Ewins <Brian.Ewins@...>

--
Aleksander Adamowski
http://olo.org.pl

$ ./nux-xpath_benchmark.sh 1.1.2
Jaxen version: 1.1.2
Classpath:
lib/nux.jar;lib/saxon8.jar;../..//xom-1.2.3_jaxen-1.1.2.jar
Environment: java 1.6.0_07, Java HotSpot(TM) Server VM, Sun Microsystems Inc., Windows XP, 5.1, x86
Now running java nux.xom.tests.XQueryBenchmark 1000 3 xom samples/data/romeo.xml samples/xpath/queries1.xml
Now reading samples/data/romeo.xml ms=250
Now reading samples/xpath/queries1.xml ms=15
query = following-sibling::* ms=156, queries/sec=6410.2563
query = preceding-sibling::* ms=63, queries/sec=15873.016
query = ancestor-or-self::* ms=31, queries/sec=32258.064
query = descendant::* ms=31, queries/sec=32258.064
query = //* ms=23250, queries/sec=43.010754
query = //line | //speaker ms=13453, queries/sec=74.33286
query = 'Hello World!' ****** XOM can't handle this query: XPath expression 'Hello World!' did not return a node-set.
ms=0, queries/sec=Infinity
query = count(//line) ****** XOM can't handle this query: XPath expression count(//line) did not return a node-set.
ms=16, queries/sec=62499.996
query = //line ms=5750, queries/sec=173.91304
query = 1+1 ****** XOM can't handle this query: XPath expression 1+1 did not return a node-set.
ms=0, queries/sec=Infinity
query = //speech[speaker = 'Rom.'] ms=5484, queries/sec=182.34865
query = //speech[speaker = 'Jul.'] ms=5469, queries/sec=182.84879
query = //line[ancestor::act[@id='5']/scene[@id='3']] ms=8875, queries/sec=112.676056
query = true() and true() and true() and true() and true() ****** XOM can't handle this query: XPath expression true() and true() and true() and true() and true() did not return a node-set.
ms=16, queries/sec=62499.996
query = //*[@id] ms=6797, queries/sec=147.12373
query = (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 ****** XOM can't handle this query: XPath expression (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 did not return a node-set.
ms=16, queries/sec=62499.996
query = contains('1234567890','9') ****** XOM can't handle this query: XPath expression contains('1234567890','9') did not return a node-set.
ms=0, queries/sec=Infinity
query = //processing-instruction() ms=6609, queries/sec=151.30882
query = following-sibling::* ms=16, queries/sec=62499.996
query = name(node()) ****** XOM can't handle this query: XPath expression name(node()) did not return a node-set.
ms=0, queries/sec=Infinity
query = sum(//act/@id) ****** XOM can't handle this query: XPath expression sum(//act/@id) did not return a node-set.
ms=15, queries/sec=66666.67
query = /guttext/play/playbody/act[@id='5']/scene[@id='3']/speech ms=78, queries/sec=12820.513
query = normalize-space(string(distinct-values(/guttext/markupmeta/gutdate))) ****** XOM can't handle this query: XPath error: No Such Function distinct-values
ms=0, queries/sec=Infinity
query = substring('12345', -42, 1.0e0 div 0) ****** XOM can't handle this query: XPath error: Expected: )
ms=0, queries/sec=Infinity
query = substring('12345', 0, 3) ****** XOM can't handle this query: XPath expression substring('12345', 0, 3) did not return a node-set.
ms=0, queries/sec=Infinity
query = substring('12345', 1.5, 2.6) ****** XOM can't handle this query: XPath expression substring('12345', 1.5, 2.6) did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod -2 ****** XOM can't handle this query: XPath expression -5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod 2 ****** XOM can't handle this query: XPath expression -5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod -2 ****** XOM can't handle this query: XPath expression 5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod 2 ****** XOM can't handle this query: XPath expression 5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = normalize-space( ' qwerty ' ) ****** XOM can't handle this query: XPath expression normalize-space( ' qwerty ' ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( 3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( 3.1415 ) ****** XOM can't handle this query: XPath expression floor( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( -3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( -3.1415 ) ****** XOM can't handle this query: XPath expression floor( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = /guttext/play/playbody/act ms=94, queries/sec=10638.298
done with repetition 0

Now reading samples/xpath/queries1.xml ms=0
query = following-sibling::* ms=47, queries/sec=21276.596
query = preceding-sibling::* ms=15, queries/sec=66666.67
query = ancestor-or-self::* ms=16, queries/sec=62499.996
query = descendant::* ms=15, queries/sec=66666.67
query = //* ms=22641, queries/sec=44.16766
query = //line | //speaker ms=13187, queries/sec=75.83226
query = 'Hello World!' ****** XOM can't handle this query: XPath expression 'Hello World!' did not return a node-set.
ms=0, queries/sec=Infinity
query = count(//line) ****** XOM can't handle this query: XPath expression count(//line) did not return a node-set.
ms=16, queries/sec=62499.996
query = //line ms=5640, queries/sec=177.30496
query = 1+1 ****** XOM can't handle this query: XPath expression 1+1 did not return a node-set.
ms=0, queries/sec=Infinity
query = //speech[speaker = 'Rom.'] ms=5297, queries/sec=188.7861
query = //speech[speaker = 'Jul.'] ms=5282, queries/sec=189.32222
query = //line[ancestor::act[@id='5']/scene[@id='3']] ms=8593, queries/sec=116.37379
query = true() and true() and true() and true() and true() ****** XOM can't handle this query: XPath expression true() and true() and true() and true() and true() did not return a node-set.
ms=0, queries/sec=Infinity
query = //*[@id] ms=6672, queries/sec=149.8801
query = (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 ****** XOM can't handle this query: XPath expression (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 did not return a node-set.
ms=16, queries/sec=62499.996
query = contains('1234567890','9') ****** XOM can't handle this query: XPath expression contains('1234567890','9') did not return a node-set.
ms=0, queries/sec=Infinity
query = //processing-instruction() ms=6484, queries/sec=154.22578
query = following-sibling::* ms=16, queries/sec=62499.996
query = name(node()) ****** XOM can't handle this query: XPath expression name(node()) did not return a node-set.
ms=0, queries/sec=Infinity
query = sum(//act/@id) ****** XOM can't handle this query: XPath expression sum(//act/@id) did not return a node-set.
ms=0, queries/sec=Infinity
query = /guttext/play/playbody/act[@id='5']/scene[@id='3']/speech ms=78, queries/sec=12820.513
query = normalize-space(string(distinct-values(/guttext/markupmeta/gutdate))) ****** XOM can't handle this query: XPath error: No Such Function distinct-values
ms=0, queries/sec=Infinity
query = substring('12345', -42, 1.0e0 div 0) ****** XOM can't handle this query: XPath error: Expected: )
ms=0, queries/sec=Infinity
query = substring('12345', 0, 3) ****** XOM can't handle this query: XPath expression substring('12345', 0, 3) did not return a node-set.
ms=0, queries/sec=Infinity
query = substring('12345', 1.5, 2.6) ****** XOM can't handle this query: XPath expression substring('12345', 1.5, 2.6) did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod -2 ****** XOM can't handle this query: XPath expression -5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod 2 ****** XOM can't handle this query: XPath expression -5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod -2 ****** XOM can't handle this query: XPath expression 5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod 2 ****** XOM can't handle this query: XPath expression 5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = normalize-space( ' qwerty ' ) ****** XOM can't handle this query: XPath expression normalize-space( ' qwerty ' ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( 3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( 3.1415 ) ****** XOM can't handle this query: XPath expression floor( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( -3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( -3.1415 ) ****** XOM can't handle this query: XPath expression floor( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = /guttext/play/playbody/act ms=15, queries/sec=66666.67
done with repetition 1

Now reading samples/xpath/queries1.xml ms=0
query = following-sibling::* ms=31, queries/sec=32258.064
query = preceding-sibling::* ms=0, queries/sec=Infinity
query = ancestor-or-self::* ms=16, queries/sec=62499.996
query = descendant::* ms=16, queries/sec=62499.996
query = //* ms=22656, queries/sec=44.138416
query = //line | //speaker ms=13312, queries/sec=75.12019
query = 'Hello World!' ****** XOM can't handle this query: XPath expression 'Hello World!' did not return a node-set.
ms=0, queries/sec=Infinity
query = count(//line) ****** XOM can't handle this query: XPath expression count(//line) did not return a node-set.
ms=0, queries/sec=Infinity
query = //line ms=5704, queries/sec=175.31557
query = 1+1 ****** XOM can't handle this query: XPath expression 1+1 did not return a node-set.
ms=0, queries/sec=Infinity
query = //speech[speaker = 'Rom.'] ms=5343, queries/sec=187.16077
query = //speech[speaker = 'Jul.'] ms=5313, queries/sec=188.21758
query = //line[ancestor::act[@id='5']/scene[@id='3']] ms=8700, queries/sec=114.94253
query = true() and true() and true() and true() and true() ****** XOM can't handle this query: XPath expression true() and true() and true() and true() and true() did not return a node-set.
ms=0, queries/sec=Infinity
query = //*[@id] ms=6656, queries/sec=150.24039
query = (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 ****** XOM can't handle this query: XPath expression (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 did not return a node-set.
ms=0, queries/sec=Infinity
query = contains('1234567890','9') ****** XOM can't handle this query: XPath expression contains('1234567890','9') did not return a node-set.
ms=0, queries/sec=Infinity
query = //processing-instruction() ms=6500, queries/sec=153.84616
query = following-sibling::* ms=0, queries/sec=Infinity
query = name(node()) ****** XOM can't handle this query: XPath expression name(node()) did not return a node-set.
ms=0, queries/sec=Infinity
query = sum(//act/@id) ****** XOM can't handle this query: XPath expression sum(//act/@id) did not return a node-set.
ms=16, queries/sec=62499.996
query = /guttext/play/playbody/act[@id='5']/scene[@id='3']/speech ms=31, queries/sec=32258.064
query = normalize-space(string(distinct-values(/guttext/markupmeta/gutdate))) ****** XOM can't handle this query: XPath error: No Such Function distinct-values
ms=0, queries/sec=Infinity
query = substring('12345', -42, 1.0e0 div 0) ****** XOM can't handle this query: XPath error: Expected: )
ms=0, queries/sec=Infinity
query = substring('12345', 0, 3) ****** XOM can't handle this query: XPath expression substring('12345', 0, 3) did not return a node-set.
ms=0, queries/sec=Infinity
query = substring('12345', 1.5, 2.6) ****** XOM can't handle this query: XPath expression substring('12345', 1.5, 2.6) did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod -2 ****** XOM can't handle this query: XPath expression -5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod 2 ****** XOM can't handle this query: XPath expression -5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod -2 ****** XOM can't handle this query: XPath expression 5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod 2 ****** XOM can't handle this query: XPath expression 5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = normalize-space( ' qwerty ' ) ****** XOM can't handle this query: XPath expression normalize-space( ' qwerty ' ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( 3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( 3.1415 ) ****** XOM can't handle this query: XPath expression floor( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( -3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( -3.1415 ) ****** XOM can't handle this query: XPath expression floor( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = /guttext/play/playbody/act ms=0, queries/sec=Infinity
done with repetition 2

$ ./nux-xpath_benchmark.sh 1.1.3
Jaxen version: 1.1.3
Classpath:
lib/nux.jar;lib/saxon8.jar;../..//xom-1.2.3_jaxen-1.1.3.jar
Environment: java 1.6.0_07, Java HotSpot(TM) Server VM, Sun Microsystems Inc., Windows XP, 5.1, x86
Now running java nux.xom.tests.XQueryBenchmark 1000 3 xom samples/data/romeo.xml samples/xpath/queries1.xml
Now reading samples/data/romeo.xml ms=266
Now reading samples/xpath/queries1.xml ms=15
query = following-sibling::* ms=187, queries/sec=5347.5933
query = preceding-sibling::* ms=47, queries/sec=21276.596
query = ancestor-or-self::* ms=47, queries/sec=21276.596
query = descendant::* ms=31, queries/sec=32258.064
query = //* ms=27594, queries/sec=36.23976
query = //line | //speaker ms=18984, queries/sec=52.67594
query = 'Hello World!' ****** XOM can't handle this query: XPath expression 'Hello World!' did not return a node-set.
ms=0, queries/sec=Infinity
query = count(//line) ****** XOM can't handle this query: XPath expression count(//line) did not return a node-set.
ms=0, queries/sec=Infinity
query = //line ms=8687, queries/sec=115.11453
query = 1+1 ****** XOM can't handle this query: XPath expression 1+1 did not return a node-set.
ms=0, queries/sec=Infinity
query = //speech[speaker = 'Rom.'] ms=8328, queries/sec=120.07685
query = //speech[speaker = 'Jul.'] ms=8078, queries/sec=123.793015
query = //line[ancestor::act[@id='5']/scene[@id='3']] ms=17063, queries/sec=58.606342
query = true() and true() and true() and true() and true() ****** XOM can't handle this query: XPath expression true() and true() and true() and true() and true() did not return a node-set.
ms=15, queries/sec=66666.67
query = //*[@id] ms=11500, queries/sec=86.95652
query = (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 ****** XOM can't handle this query: XPath expression (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 did not return a node-set.
ms=16, queries/sec=62499.996
query = contains('1234567890','9') ****** XOM can't handle this query: XPath expression contains('1234567890','9') did not return a node-set.
ms=0, queries/sec=Infinity
query = //processing-instruction() ms=7891, queries/sec=126.726654
query = following-sibling::* ms=15, queries/sec=66666.67
query = name(node()) ****** XOM can't handle this query: XPath expression name(node()) did not return a node-set.
ms=0, queries/sec=Infinity
query = sum(//act/@id) ****** XOM can't handle this query: XPath expression sum(//act/@id) did not return a node-set.
ms=16, queries/sec=62499.996
query = /guttext/play/playbody/act[@id='5']/scene[@id='3']/speech ms=94, queries/sec=10638.298
query = normalize-space(string(distinct-values(/guttext/markupmeta/gutdate))) ****** XOM can't handle this query: XPath error: No Such Function distinct-values
ms=0, queries/sec=Infinity
query = substring('12345', -42, 1.0e0 div 0) ****** XOM can't handle this query: XPath error: Expected: )
ms=0, queries/sec=Infinity
query = substring('12345', 0, 3) ****** XOM can't handle this query: XPath expression substring('12345', 0, 3) did not return a node-set.
ms=0, queries/sec=Infinity
query = substring('12345', 1.5, 2.6) ****** XOM can't handle this query: XPath expression substring('12345', 1.5, 2.6) did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod -2 ****** XOM can't handle this query: XPath expression -5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod 2 ****** XOM can't handle this query: XPath expression -5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod -2 ****** XOM can't handle this query: XPath expression 5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod 2 ****** XOM can't handle this query: XPath expression 5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = normalize-space( ' qwerty ' ) ****** XOM can't handle this query: XPath expression normalize-space( ' qwerty ' ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( 3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( 3.1415 ) ****** XOM can't handle this query: XPath expression floor( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( -3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( -3.1415 ) ****** XOM can't handle this query: XPath expression floor( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = /guttext/play/playbody/act ms=110, queries/sec=9090.909
done with repetition 0

Now reading samples/xpath/queries1.xml ms=0
query = following-sibling::* ms=78, queries/sec=12820.513
query = preceding-sibling::* ms=47, queries/sec=21276.596
query = ancestor-or-self::* ms=15, queries/sec=66666.67
query = descendant::* ms=32, queries/sec=31249.998
query = //* ms=27421, queries/sec=36.4684
query = //line | //speaker ms=19500, queries/sec=51.28205
query = 'Hello World!' ****** XOM can't handle this query: XPath expression 'Hello World!' did not return a node-set.
ms=0, queries/sec=Infinity
query = count(//line) ****** XOM can't handle this query: XPath expression count(//line) did not return a node-set.
ms=0, queries/sec=Infinity
query = //line ms=8750, queries/sec=114.28571
query = 1+1 ****** XOM can't handle this query: XPath expression 1+1 did not return a node-set.
ms=0, queries/sec=Infinity
query = //speech[speaker = 'Rom.'] ms=8141, queries/sec=122.83504
query = //speech[speaker = 'Jul.'] ms=8125, queries/sec=123.07692
query = //line[ancestor::act[@id='5']/scene[@id='3']] ms=16938, queries/sec=59.03885
query = true() and true() and true() and true() and true() ****** XOM can't handle this query: XPath expression true() and true() and true() and true() and true() did not return a node-set.
ms=0, queries/sec=Infinity
query = //*[@id] ms=11484, queries/sec=87.077675
query = (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 ****** XOM can't handle this query: XPath expression (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 did not return a node-set.
ms=0, queries/sec=Infinity
query = contains('1234567890','9') ****** XOM can't handle this query: XPath expression contains('1234567890','9') did not return a node-set.
ms=0, queries/sec=Infinity
query = //processing-instruction() ms=7812, queries/sec=128.0082
query = following-sibling::* ms=16, queries/sec=62499.996
query = name(node()) ****** XOM can't handle this query: XPath expression name(node()) did not return a node-set.
ms=0, queries/sec=Infinity
query = sum(//act/@id) ****** XOM can't handle this query: XPath expression sum(//act/@id) did not return a node-set.
ms=0, queries/sec=Infinity
query = /guttext/play/playbody/act[@id='5']/scene[@id='3']/speech ms=47, queries/sec=21276.596
query = normalize-space(string(distinct-values(/guttext/markupmeta/gutdate))) ****** XOM can't handle this query: XPath error: No Such Function distinct-values
ms=0, queries/sec=Infinity
query = substring('12345', -42, 1.0e0 div 0) ****** XOM can't handle this query: XPath error: Expected: )
ms=0, queries/sec=Infinity
query = substring('12345', 0, 3) ****** XOM can't handle this query: XPath expression substring('12345', 0, 3) did not return a node-set.
ms=0, queries/sec=Infinity
query = substring('12345', 1.5, 2.6) ****** XOM can't handle this query: XPath expression substring('12345', 1.5, 2.6) did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod -2 ****** XOM can't handle this query: XPath expression -5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod 2 ****** XOM can't handle this query: XPath expression -5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod -2 ****** XOM can't handle this query: XPath expression 5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod 2 ****** XOM can't handle this query: XPath expression 5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = normalize-space( ' qwerty ' ) ****** XOM can't handle this query: XPath expression normalize-space( ' qwerty ' ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( 3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( 3.1415 ) ****** XOM can't handle this query: XPath expression floor( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( -3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( -3.1415 ) ****** XOM can't handle this query: XPath expression floor( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = /guttext/play/playbody/act ms=15, queries/sec=66666.67
done with repetition 1

Now reading samples/xpath/queries1.xml ms=0
query = following-sibling::* ms=63, queries/sec=15873.016
query = preceding-sibling::* ms=15, queries/sec=66666.67
query = ancestor-or-self::* ms=0, queries/sec=Infinity
query = descendant::* ms=0, queries/sec=Infinity
query = //* ms=27453, queries/sec=36.42589
query = //line | //speaker ms=19516, queries/sec=51.240005
query = 'Hello World!' ****** XOM can't handle this query: XPath expression 'Hello World!' did not return a node-set.
ms=0, queries/sec=Infinity
query = count(//line) ****** XOM can't handle this query: XPath expression count(//line) did not return a node-set.
ms=0, queries/sec=Infinity
query = //line ms=8750, queries/sec=114.28571
query = 1+1 ****** XOM can't handle this query: XPath expression 1+1 did not return a node-set.
ms=0, queries/sec=Infinity
query = //speech[speaker = 'Rom.'] ms=8140, queries/sec=122.85012
query = //speech[speaker = 'Jul.'] ms=8125, queries/sec=123.07692
query = //line[ancestor::act[@id='5']/scene[@id='3']] ms=16891, queries/sec=59.203125
query = true() and true() and true() and true() and true() ****** XOM can't handle this query: XPath expression true() and true() and true() and true() and true() did not return a node-set.
ms=0, queries/sec=Infinity
query = //*[@id] ms=11484, queries/sec=87.077675
query = (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 ****** XOM can't handle this query: XPath expression (count(descendant::*) + count(ancestor::*) + count(following::*) + count(preceding::*)) >= 5034 did not return a node-set.
ms=0, queries/sec=Infinity
query = contains('1234567890','9') ****** XOM can't handle this query: XPath expression contains('1234567890','9') did not return a node-set.
ms=0, queries/sec=Infinity
query = //processing-instruction() ms=7828, queries/sec=127.74655
query = following-sibling::* ms=16, queries/sec=62499.996
query = name(node()) ****** XOM can't handle this query: XPath expression name(node()) did not return a node-set.
ms=0, queries/sec=Infinity
query = sum(//act/@id) ****** XOM can't handle this query: XPath expression sum(//act/@id) did not return a node-set.
ms=0, queries/sec=Infinity
query = /guttext/play/playbody/act[@id='5']/scene[@id='3']/speech ms=63, queries/sec=15873.016
query = normalize-space(string(distinct-values(/guttext/markupmeta/gutdate))) ****** XOM can't handle this query: XPath error: No Such Function distinct-values
ms=0, queries/sec=Infinity
query = substring('12345', -42, 1.0e0 div 0) ****** XOM can't handle this query: XPath error: Expected: )
ms=0, queries/sec=Infinity
query = substring('12345', 0, 3) ****** XOM can't handle this query: XPath expression substring('12345', 0, 3) did not return a node-set.
ms=0, queries/sec=Infinity
query = substring('12345', 1.5, 2.6) ****** XOM can't handle this query: XPath expression substring('12345', 1.5, 2.6) did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod -2 ****** XOM can't handle this query: XPath expression -5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = -5 mod 2 ****** XOM can't handle this query: XPath expression -5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod -2 ****** XOM can't handle this query: XPath expression 5 mod -2 did not return a node-set.
ms=0, queries/sec=Infinity
query = 5 mod 2 ****** XOM can't handle this query: XPath expression 5 mod 2 did not return a node-set.
ms=0, queries/sec=Infinity
query = normalize-space( ' qwerty ' ) ****** XOM can't handle this query: XPath expression normalize-space( ' qwerty ' ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( 3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( 3.1415 ) ****** XOM can't handle this query: XPath expression floor( 3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = ceiling( -3.1415 ) ****** XOM can't handle this query: XPath expression ceiling( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = floor( -3.1415 ) ****** XOM can't handle this query: XPath expression floor( -3.1415 ) did not return a node-set.
ms=0, queries/sec=Infinity
query = /guttext/play/playbody/act ms=15, queries/sec=66666.67
done with repetition 2

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: jaxen - dev

[jira] Commented: (JAXEN-206) bad order when context is a list of nodes at different depths

2009-10-21T05:37:26Z

[ http://jira.codehaus.org/browse/JAXEN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195447#action_195447 ]

Brian Ewins commented on JAXEN-206:
-----------------------------------

Its not going to affect many people. I remember years ago someone asking on the list about passing in lists - they were using some non-xpath criteria to create the context. But while the example above will only affect people relying on jaxen's contract that it will return nodes in document order, its possible to turn this into an evaluation error for everyone:

XPath xpath = new DOMXPath("local-name(parent::*)");
assertEquals("z", xpath.stringValueOf(context));

From forum: jaxen - dev

[jira] Commented: (JAXEN-206) bad order when context is a list of nodes at different depths

2009-10-21T04:45:26Z

[ http://jira.codehaus.org/browse/JAXEN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195443#action_195443 ]

Elliotte Rusty Harold commented on JAXEN-206:
---------------------------------------------

I'll try and patch this in soon. Meanwhile, do you know who to talk to to get committer access back? I don't think I can do it.

How bad is this? Will this only affect someone calling a more-or-less internal method in the API, or is it possible this could cause incorrect XPath evaluation on actual documents?

From forum: jaxen - dev

[jira] Updated: (JAXEN-206) bad order when context is a list of nodes at different depths

2009-10-21T04:27:27Z

[ http://jira.codehaus.org/browse/JAXEN-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Ewins updated JAXEN-206:
------------------------------

Description:
As described by Elliotte on the list:
Consider this:

<z>
<a>

</a>
<c/>
</z>

Suppose the list includes b and c in document order. c's parent
precedes b's parent even though b precedes c

When calling xpath.selectNodes(context) we can supply a list of nodes instead of a single node. By supplying a list containing b and c as described above, and selecting "parent::*", we should get the list [z, a] returned. Instead we get [a, z]. The reason is that DefaultLocationPath does not sort the nodes into document order when there is only a single step in the location path.

Patch attached, including test case.

was:
As described by Elliotte on the list:
Consider this:

<z>
<a>

</a>
<c/>
</z>

Suppose the list includes b and c in document order. c's parent
precedes b's parent even though b precedes c

When calling xpath.selectNodes(context) we can supply a list of nodes instead of a single node. By supplying a list containing b and c as described above, and selecting "parent::*", we should get the list [z, a] returInstead we get [a, z]. The reason is that DefaultLocationPath does not sort the nodes into document order when there is only a single step in the location path.

Patch attached, including test case.

From forum: jaxen - dev

[jira] Created: (JAXEN-206) bad order when context is a list of nodes at different depths

2009-10-21T04:27:27Z

bad order when context is a list of nodes at different depths
-------------------------------------------------------------

Key: JAXEN-206
URL: http://jira.codehaus.org/browse/JAXEN-206
Project: jaxen
Issue Type: Bug
Components: core
Affects Versions: 1.1.3
Reporter: Brian Ewins
Attachments: mismatch.patch

As described by Elliotte on the list:
Consider this:

<z>
<a>

</a>
<c/>
</z>

Suppose the list includes b and c in document order. c's parent
precedes b's parent even though b precedes c

When calling xpath.selectNodes(context) we can supply a list of nodes instead of a single node. By supplying a list containing b and c as described above, and selecting "parent::*", we should get the list [z, a] returInstead we get [a, z]. The reason is that DefaultLocationPath does not sort the nodes into document order when there is only a single step in the location path.

Patch attached, including test case.

--
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

From forum: jaxen - dev

Re: [jira] Updated: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-21T04:02:35Z

2009/10/20 Baz <brian.ewins@...>:

> 2009/10/20 Elliotte Rusty Harold <elharo@...>:
>> On Tue, Oct 20, 2009 at 5:30 AM, Brian Ewins (JIRA) <jira@...> wrote:
>>>
>>> [ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>>
>>> Brian Ewins updated JAXEN-31:
>>> -----------------------------
>>>
>>> Attachment: perf.patch
>>>
>>> Ok, I have gone one step further and turned off the sort whenever the location path only uses the parent, self, or child axes (a very common case). The theory here is that given a list of nodes X in document order, then X/parent::*, X/self::*, and X/child::* are also in document order; that a whole location path consisting of these axes is also ordered follows by induction. Other axes do not support this assertion, and removing the sort for them would trigger JAXEN-55. Do you agree with this analysis Elliotte?
>>>
>>
>> I don't think so, at least not for the parent axis. Consider this:
>>
>> <z>
>> <a>
>> 
>> </a>
>> <c/>
>> </z>
>>
>> Suppose the list includes b and c in document order. c's parent
>> precedes b's parent even though b precedes c (unless I'm forgetting
>> the exact rules for document order, which is possible)
>>
>
> Hmm, I've slightly misstated myself - I knew we'd get problems like
> that if the depth varied, that's what jaxen-55 is about. X was
> supposed to be nodes in document order /at the same depth/. The three
> axes I mentioned (also attribute:: and namespace::) produce result
> nodes which all have the same depth too, and preserve order for that
> case only. (the sibling axes preserve depth but not order)
>
> If the assumption that the initial nodeset X is not sorted and the
> same depth is incorrect, then we have another bug: the current jaxen
> code does not sort after evaluating a single step, eg if we started
> with {b, c} in your example.

Ok - we do in fact have this bug, here's a test case based on your email:

public void testMismatchedDepthsInContext()
throws JaxenException {
XPath xpath = new DOMXPath("parent::*");
org.w3c.dom.Element z = doc.createElementNS("", "z");
doc.appendChild(z);
org.w3c.dom.Element a = doc.createElementNS("", "a");
z.appendChild(a);
org.w3c.dom.Element b = doc.createElementNS("", "b");
a.appendChild(b);
org.w3c.dom.Element c = doc.createElementNS("", "c");
z.appendChild(c);

List context = new ArrayList();
context.add(b);
context.add(c);
List result = xpath.selectNodes(context);
assertEquals(z, result.get(0));
}

Ouch. Fixing current jaxen and the fast path patch is easiest if we
just check that the context size is 1 (otherwise require the sort).

This (in DefaultLocationPath) fixes the bug in svn HEAD:

- if (getSteps().size() > 1) {
+ if (getSteps().size() > 1|| nodeSet.size() > 1) {

the fix in the perf patch is a bit more involved as we want to avoid
that second call to size(); however I have a working fix. I'll post a
bug report, patch etc.

-Baz

>
> Hopefully we don't allow the user to supply a list as the context... I
> don't have the code in front of me.
>
> -Baz
>>
>> --
>> Elliotte Rusty Harold
>> elharo@...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: jaxen - dev

Re: [jira] Updated: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-20T15:29:56Z

2009/10/20 Elliotte Rusty Harold <elharo@...>:

> On Tue, Oct 20, 2009 at 5:30 AM, Brian Ewins (JIRA) <jira@...> wrote:
>>
>> [ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>>
>> Brian Ewins updated JAXEN-31:
>> -----------------------------
>>
>> Attachment: perf.patch
>>
>> Ok, I have gone one step further and turned off the sort whenever the location path only uses the parent, self, or child axes (a very common case). The theory here is that given a list of nodes X in document order, then X/parent::*, X/self::*, and X/child::* are also in document order; that a whole location path consisting of these axes is also ordered follows by induction. Other axes do not support this assertion, and removing the sort for them would trigger JAXEN-55. Do you agree with this analysis Elliotte?
>>
>
> I don't think so, at least not for the parent axis. Consider this:
>
> <z>
> <a>
> 
> </a>
> <c/>
> </z>
>
> Suppose the list includes b and c in document order. c's parent
> precedes b's parent even though b precedes c (unless I'm forgetting
> the exact rules for document order, which is possible)
>

Hmm, I've slightly misstated myself - I knew we'd get problems like
that if the depth varied, that's what jaxen-55 is about. X was
supposed to be nodes in document order /at the same depth/. The three
axes I mentioned (also attribute:: and namespace::) produce result
nodes which all have the same depth too, and preserve order for that
case only. (the sibling axes preserve depth but not order)

If the assumption that the initial nodeset X is not sorted and the
same depth is incorrect, then we have another bug: the current jaxen
code does not sort after evaluating a single step, eg if we started
with {b, c} in your example.

Hopefully we don't allow the user to supply a list as the context... I
don't have the code in front of me.

-Baz

>
> --
> Elliotte Rusty Harold
> elharo@...
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: jaxen - dev

Re: [jira] Updated: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-20T13:38:27Z

On Tue, Oct 20, 2009 at 5:30 AM, Brian Ewins (JIRA) <jira@...> wrote:

>
> [ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Brian Ewins updated JAXEN-31:
> -----------------------------
>
> Attachment: perf.patch
>
> Ok, I have gone one step further and turned off the sort whenever the location path only uses the parent, self, or child axes (a very common case). The theory here is that given a list of nodes X in document order, then X/parent::*, X/self::*, and X/child::* are also in document order; that a whole location path consisting of these axes is also ordered follows by induction. Other axes do not support this assertion, and removing the sort for them would trigger JAXEN-55. Do you agree with this analysis Elliotte?
>

I don't think so, at least not for the parent axis. Consider this:

<z>
<a>

</a>
<c/>
</z>

Suppose the list includes b and c in document order. c's parent
precedes b's parent even though b precedes c (unless I'm forgetting
the exact rules for document order, which is possible)

--
Elliotte Rusty Harold
elharo@...

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

From forum: jaxen - dev

[jira] Updated: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-20T02:30:27Z

[ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Ewins updated JAXEN-31:
-----------------------------

Attachment: perf.patch

Ok, I have gone one step further and turned off the sort whenever the location path only uses the parent, self, or child axes (a very common case). The theory here is that given a list of nodes X in document order, then X/parent::*, X/self::*, and X/child::* are also in document order; that a whole location path consisting of these axes is also ordered follows by induction. Other axes do not support this assertion, and removing the sort for them would trigger JAXEN-55. Do you agree with this analysis Elliotte?

All tests still pass. The performance gains are back towards the title of this bug - XOMPerformance goes from 4.9s to 97ms on my machine. Its a shame I can't get this simple trick to work for descendant-or-self but this is quite a big win as it stands.

From forum: jaxen - dev

[jira] Updated: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-19T11:12:27Z

[ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Ewins updated JAXEN-31:
-----------------------------

Attachment: perf.patch

This version of the patch passes all tests (w00t!), and reduces the number of places that force the lazy list to be filled. I've refactored the lazy list itself a bit, so that a separate method, fill(), is called when filling is forced for the first time. This makes it easy to find the culprits in the debugger.

Debugging XOMPerformance.java, there is only one culprit - the call to Collections.sort() in DefaultLocationPath. Sorting should always be unnecessary - since we deal with nodes that are either already sorted in a forward or reverse direction, we at most need to perform a reverse and a merge.

BTW, I am seeing this version as being /slower/ for that test than svn head - 5.9s versus 4.9s. Seems like a lot of overhead wrapping iterators in lists in iterators... Aleksander, how does this perform in your real world case?

> if jaxen stopped using lists it would be 37x faster
> ---------------------------------------------------
>
> Key: JAXEN-31
> URL: http://jira.codehaus.org/browse/JAXEN-31
> Project: jaxen
> Issue Type: Improvement
> Affects Versions: 1.0
> Reporter: Brian Ewins
> Fix For: 2.0
>
> Attachments: Brian_Ewins_JAXEN-31_perf.patch, jaxen.zip, perf.patch, perf.patch, stuff.tgz
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> The short story - I've rewritten jaxen to use a nodeset abstraction instead of a list to accumulate results. With the unit tests at nearly 100%, the performance test on dom4j runs in ~200ms on my 1GHz powerbook, compared to ~7400ms for the nightly jaxen build. The failing unit tests are for paths not covered in the performance test.
> The long story - I wrote an implementation of the draft ISO Schematron spec on top of Jaxen, instead of the more usual XSLT. The schematron spec is designed so this can be done, mainly for performance reasons. Once I had enough working I was able to compare jaxen with xalan on the 'screamatron' torture test, which is using schematron to validate the schematron 1.5 spec. I was suprised to find that jaxen was about 2x /slower/ than xalan, and marginally slower with a jdom navigator than a dom4j navigator. Looking at why it was so slow, it became clear that the problem was that throughout jaxen it's building lists of intermediate results to filter down, instead of generating the 'next' result on demand. There's comments about this in several places in the code, but the list thing is so ingrained it needs more than a little refactoring to fix.
> I decided to have a go. This change produces apis incompatible with previous versions of jaxen, so this will be a lump of code not a wee patch. I've basically cloned jaxen to 'org.jaxen2' to work on it. I'm nearly done with the changes, failing tests for the non-xpath extension functions which I havent implemented yet, patterns (not touched at all yet), and a couple of minor bugs.
> I'll post the code on jira once I'm done, but here's the gist of the changes I made:
> - Introduce a Nodeset abstraction instead of a list...
> public interface extends Iterator {
> Object current();
> int position();
> // use of last() replaces the internal iterator with an iterator over a list caching results.
> // it's basically a fallback on what jaxen used to do.
> int last();
> }
> the reason for this is obvious, eg you can just test 'hasNext()' to check the boolean value of a nodeset.
> - change the signature of Expr to allow the selection of a fast code path
> public interface Expr {
> // these require context because of variable/function refs only. see later.
> boolean isBoolean(Context ctx);
> boolean isNumber(Context ctx);
> boolean isString(Context ctx);
> boolean isNodeset(Context ctx);
> boolean booleanValue(Context ctx);
> double numberValue(Context ctx);
> String stringValue(Context ctx);
> Nodeset nodesetValue(Context ctx);
> // etc
> }
> this is really for my own sanity as there's so much code to maintain. Throughout jaxen, everything is untyped, so its fairly easy to (eg) pass a nodeSet when you meant to pass a node; there's instanceof checks, == null checks, and casts everywhere to deal with this. Once you put everything behind an interface like the one above, making objects responsible for their own casts, a lot of the code is simplified, eg addition is just expr1.numberValue(ctx) + expr2.numberValue(ctx). All but a couple of classes inherit from abstract base classes that implement all but one of those methods (eg StringExprBase leaves stringValue() abstract.)
> Variable/Function refs don't have a type without context in my version, and like Jaxen I look up functions, variables every time. This isn't smart - in xpath we can resolve all variable, function refs beforehand, and get faster code as a result. I'll probably change things so I have 'bound' and 'unbound' exprs, add 'BoundExpr bind(VariableContext,FunctionContext)'. I'll still need to pass these as members of Context to support the 'evaluate' extension function though.
> Another approach to the same concern that I didn't try is to pass in a typed context, eg 'StringContext', 'NodesetContext', etc (think of this as allowing things like perl's 'wantarray()'. That approach would make it easier to expand the number of supported types (eg for xpath2) in future, I'll try it once the tests pass.
> - moved all the functions to a single utility class
> public class Functions {
> String substring(String s, double start, double end);
> // etc
> }
> this makes it easier to unit test the xpath functions, since they are mostly context-independent. Functions that need a navigator get it passed as the first arg, functions that optionally use the context node instead of an argument have that function added as a method of Context. Incidentally I changed some of the unit tests to get mine to pass - in particular I changed the substring() tests back to match the spec (they don't currently).
> No function in my version returns null. (compare to eg the name, namespaceuri functions of Navigator). The xpath spec uses "" or an empty nodeset throughout, so do I, this gets rid of a lot of == null checks.
> Some of the bugs against the current version of jaxen are fixed by this code - eg the use of double throughout allows gt/lt comparisons of longs (bug jaxen-28), + both of the bugs I filed previously.
> I'd estimate I can finish this in the next week.

From forum: jaxen - dev

[jira] Commented: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-19T06:14:26Z

[ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195242#action_195242 ]

Brian Ewins commented on JAXEN-31:
----------------------------------

(A bit off topic here) yes, or more accurately I was a committer. I hadn't pushed anything for a while, and then an ssh key vulnerability was announced, which led to all vulnerable ssh keys - including mine - being disabled everywhere. I never submitted a new one, so effectively I'm out of the loop. I'm still monitoring the mailing list and following you on twitter tho!

Also, I wouldn't expect to see this land until all the tests pass; its not quite there yet, though its not far off (2 real failures now). So pushing all of this isn't an option for now, though as I see you've just commented elsewhere, landing bits of it, like isEmpty(), might be useful.

> if jaxen stopped using lists it would be 37x faster
> ---------------------------------------------------
>
> Key: JAXEN-31
> URL: http://jira.codehaus.org/browse/JAXEN-31
> Project: jaxen
> Issue Type: Improvement
> Affects Versions: 1.0
> Reporter: Brian Ewins
> Fix For: 2.0
>
> Attachments: Brian_Ewins_JAXEN-31_perf.patch, jaxen.zip, perf.patch, stuff.tgz
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> The short story - I've rewritten jaxen to use a nodeset abstraction instead of a list to accumulate results. With the unit tests at nearly 100%, the performance test on dom4j runs in ~200ms on my 1GHz powerbook, compared to ~7400ms for the nightly jaxen build. The failing unit tests are for paths not covered in the performance test.
> The long story - I wrote an implementation of the draft ISO Schematron spec on top of Jaxen, instead of the more usual XSLT. The schematron spec is designed so this can be done, mainly for performance reasons. Once I had enough working I was able to compare jaxen with xalan on the 'screamatron' torture test, which is using schematron to validate the schematron 1.5 spec. I was suprised to find that jaxen was about 2x /slower/ than xalan, and marginally slower with a jdom navigator than a dom4j navigator. Looking at why it was so slow, it became clear that the problem was that throughout jaxen it's building lists of intermediate results to filter down, instead of generating the 'next' result on demand. There's comments about this in several places in the code, but the list thing is so ingrained it needs more than a little refactoring to fix.
> I decided to have a go. This change produces apis incompatible with previous versions of jaxen, so this will be a lump of code not a wee patch. I've basically cloned jaxen to 'org.jaxen2' to work on it. I'm nearly done with the changes, failing tests for the non-xpath extension functions which I havent implemented yet, patterns (not touched at all yet), and a couple of minor bugs.
> I'll post the code on jira once I'm done, but here's the gist of the changes I made:
> - Introduce a Nodeset abstraction instead of a list...
> public interface extends Iterator {
> Object current();
> int position();
> // use of last() replaces the internal iterator with an iterator over a list caching results.
> // it's basically a fallback on what jaxen used to do.
> int last();
> }
> the reason for this is obvious, eg you can just test 'hasNext()' to check the boolean value of a nodeset.
> - change the signature of Expr to allow the selection of a fast code path
> public interface Expr {
> // these require context because of variable/function refs only. see later.
> boolean isBoolean(Context ctx);
> boolean isNumber(Context ctx);
> boolean isString(Context ctx);
> boolean isNodeset(Context ctx);
> boolean booleanValue(Context ctx);
> double numberValue(Context ctx);
> String stringValue(Context ctx);
> Nodeset nodesetValue(Context ctx);
> // etc
> }
> this is really for my own sanity as there's so much code to maintain. Throughout jaxen, everything is untyped, so its fairly easy to (eg) pass a nodeSet when you meant to pass a node; there's instanceof checks, == null checks, and casts everywhere to deal with this. Once you put everything behind an interface like the one above, making objects responsible for their own casts, a lot of the code is simplified, eg addition is just expr1.numberValue(ctx) + expr2.numberValue(ctx). All but a couple of classes inherit from abstract base classes that implement all but one of those methods (eg StringExprBase leaves stringValue() abstract.)
> Variable/Function refs don't have a type without context in my version, and like Jaxen I look up functions, variables every time. This isn't smart - in xpath we can resolve all variable, function refs beforehand, and get faster code as a result. I'll probably change things so I have 'bound' and 'unbound' exprs, add 'BoundExpr bind(VariableContext,FunctionContext)'. I'll still need to pass these as members of Context to support the 'evaluate' extension function though.
> Another approach to the same concern that I didn't try is to pass in a typed context, eg 'StringContext', 'NodesetContext', etc (think of this as allowing things like perl's 'wantarray()'. That approach would make it easier to expand the number of supported types (eg for xpath2) in future, I'll try it once the tests pass.
> - moved all the functions to a single utility class
> public class Functions {
> String substring(String s, double start, double end);
> // etc
> }
> this makes it easier to unit test the xpath functions, since they are mostly context-independent. Functions that need a navigator get it passed as the first arg, functions that optionally use the context node instead of an argument have that function added as a method of Context. Incidentally I changed some of the unit tests to get mine to pass - in particular I changed the substring() tests back to match the spec (they don't currently).
> No function in my version returns null. (compare to eg the name, namespaceuri functions of Navigator). The xpath spec uses "" or an empty nodeset throughout, so do I, this gets rid of a lot of == null checks.
> Some of the bugs against the current version of jaxen are fixed by this code - eg the use of double throughout allows gt/lt comparisons of longs (bug jaxen-28), + both of the bugs I filed previously.
> I'd estimate I can finish this in the next week.

From forum: jaxen - dev

[jira] Commented: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-19T05:52:27Z

[ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=195236#action_195236 ]

Elliotte Rusty Harold commented on JAXEN-31:
--------------------------------------------

Looking good. I would like to get the failed tests down to zero though.

We could probably make Context immutable as part of a larger revision.

Brian, you're a committer right?

> if jaxen stopped using lists it would be 37x faster
> ---------------------------------------------------
>
> Key: JAXEN-31
> URL: http://jira.codehaus.org/browse/JAXEN-31
> Project: jaxen
> Issue Type: Improvement
> Affects Versions: 1.0
> Reporter: Brian Ewins
> Fix For: 2.0
>
> Attachments: Brian_Ewins_JAXEN-31_perf.patch, jaxen.zip, perf.patch, stuff.tgz
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> The short story - I've rewritten jaxen to use a nodeset abstraction instead of a list to accumulate results. With the unit tests at nearly 100%, the performance test on dom4j runs in ~200ms on my 1GHz powerbook, compared to ~7400ms for the nightly jaxen build. The failing unit tests are for paths not covered in the performance test.
> The long story - I wrote an implementation of the draft ISO Schematron spec on top of Jaxen, instead of the more usual XSLT. The schematron spec is designed so this can be done, mainly for performance reasons. Once I had enough working I was able to compare jaxen with xalan on the 'screamatron' torture test, which is using schematron to validate the schematron 1.5 spec. I was suprised to find that jaxen was about 2x /slower/ than xalan, and marginally slower with a jdom navigator than a dom4j navigator. Looking at why it was so slow, it became clear that the problem was that throughout jaxen it's building lists of intermediate results to filter down, instead of generating the 'next' result on demand. There's comments about this in several places in the code, but the list thing is so ingrained it needs more than a little refactoring to fix.
> I decided to have a go. This change produces apis incompatible with previous versions of jaxen, so this will be a lump of code not a wee patch. I've basically cloned jaxen to 'org.jaxen2' to work on it. I'm nearly done with the changes, failing tests for the non-xpath extension functions which I havent implemented yet, patterns (not touched at all yet), and a couple of minor bugs.
> I'll post the code on jira once I'm done, but here's the gist of the changes I made:
> - Introduce a Nodeset abstraction instead of a list...
> public interface extends Iterator {
> Object current();
> int position();
> // use of last() replaces the internal iterator with an iterator over a list caching results.
> // it's basically a fallback on what jaxen used to do.
> int last();
> }
> the reason for this is obvious, eg you can just test 'hasNext()' to check the boolean value of a nodeset.
> - change the signature of Expr to allow the selection of a fast code path
> public interface Expr {
> // these require context because of variable/function refs only. see later.
> boolean isBoolean(Context ctx);
> boolean isNumber(Context ctx);
> boolean isString(Context ctx);
> boolean isNodeset(Context ctx);
> boolean booleanValue(Context ctx);
> double numberValue(Context ctx);
> String stringValue(Context ctx);
> Nodeset nodesetValue(Context ctx);
> // etc
> }
> this is really for my own sanity as there's so much code to maintain. Throughout jaxen, everything is untyped, so its fairly easy to (eg) pass a nodeSet when you meant to pass a node; there's instanceof checks, == null checks, and casts everywhere to deal with this. Once you put everything behind an interface like the one above, making objects responsible for their own casts, a lot of the code is simplified, eg addition is just expr1.numberValue(ctx) + expr2.numberValue(ctx). All but a couple of classes inherit from abstract base classes that implement all but one of those methods (eg StringExprBase leaves stringValue() abstract.)
> Variable/Function refs don't have a type without context in my version, and like Jaxen I look up functions, variables every time. This isn't smart - in xpath we can resolve all variable, function refs beforehand, and get faster code as a result. I'll probably change things so I have 'bound' and 'unbound' exprs, add 'BoundExpr bind(VariableContext,FunctionContext)'. I'll still need to pass these as members of Context to support the 'evaluate' extension function though.
> Another approach to the same concern that I didn't try is to pass in a typed context, eg 'StringContext', 'NodesetContext', etc (think of this as allowing things like perl's 'wantarray()'. That approach would make it easier to expand the number of supported types (eg for xpath2) in future, I'll try it once the tests pass.
> - moved all the functions to a single utility class
> public class Functions {
> String substring(String s, double start, double end);
> // etc
> }
> this makes it easier to unit test the xpath functions, since they are mostly context-independent. Functions that need a navigator get it passed as the first arg, functions that optionally use the context node instead of an argument have that function added as a method of Context. Incidentally I changed some of the unit tests to get mine to pass - in particular I changed the substring() tests back to match the spec (they don't currently).
> No function in my version returns null. (compare to eg the name, namespaceuri functions of Navigator). The xpath spec uses "" or an empty nodeset throughout, so do I, this gets rid of a lot of == null checks.
> Some of the bugs against the current version of jaxen are fixed by this code - eg the use of double throughout allows gt/lt comparisons of longs (bug jaxen-28), + both of the bugs I filed previously.
> I'd estimate I can finish this in the next week.

From forum: jaxen - dev

[jira] Updated: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-19T05:07:27Z

[ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Ewins updated JAXEN-31:
-----------------------------

Attachment: perf.patch

Aleksander commented that there were still a few hotspots in this version, checking isElement() etc. I had a look over the code for any obvious optimisations. I think the tests we do there are unavoidable, and the number of calls ought to match up with released version of jaxen. However, I did spot a few further improvements.

First thing: it turns out that removing the new ArrayList() from "Collections.reverse(new ArrayList(contextNodeSet));" in DefaultLocationPath took my failed tests down to 6 (really 2, duplicated because IDEA runs the suites and the tests). Its unclear to me why this would have any effect at all (which is worrying).

Next, optimisations: there were a few things that jumped out. Any time we call context.size() we force the LazyLists introduced in the previous patch to fill up. The code quite nastily uses 'list.size() == 0' to test for emptiness, rather than using 'list.isEmpty()'. That's just bad, there's no need to know the actual size to test if a list is empty, and the LazyLists are optimised for that case; so I replaced those. There was also an avoidable use of size() testing 'size() ==1' prior to a list.get(0); I fixed this to use the iterator. DefaultStep was not using iterators, so non-name-steps were evaluating the size. Fixing all of this did not change the test situation at all, but should have a good impact on perf.

There's two users of size() which are more complicated: PredicateSet and Context. Context is mutable, which is a big mistake; worse, the size, position, and nodeset are mutable separately. In order for some of the logic to work, if the nodeset changes, the position may need reset to zero; but only if the position is not explicitly set before it is used. Anyway, I've updated that code slightly so that the right thing happens, but where possible we avoid calling nodeset.size(). I've not updated the PredicateSet code - which is more complicated - so it remains the case that uses of predicates will trigger slow paths.

patch attached.

> if jaxen stopped using lists it would be 37x faster
> ---------------------------------------------------
>
> Key: JAXEN-31
> URL: http://jira.codehaus.org/browse/JAXEN-31
> Project: jaxen
> Issue Type: Improvement
> Affects Versions: 1.0
> Reporter: Brian Ewins
> Fix For: 2.0
>
> Attachments: Brian_Ewins_JAXEN-31_perf.patch, jaxen.zip, perf.patch, stuff.tgz
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> The short story - I've rewritten jaxen to use a nodeset abstraction instead of a list to accumulate results. With the unit tests at nearly 100%, the performance test on dom4j runs in ~200ms on my 1GHz powerbook, compared to ~7400ms for the nightly jaxen build. The failing unit tests are for paths not covered in the performance test.
> The long story - I wrote an implementation of the draft ISO Schematron spec on top of Jaxen, instead of the more usual XSLT. The schematron spec is designed so this can be done, mainly for performance reasons. Once I had enough working I was able to compare jaxen with xalan on the 'screamatron' torture test, which is using schematron to validate the schematron 1.5 spec. I was suprised to find that jaxen was about 2x /slower/ than xalan, and marginally slower with a jdom navigator than a dom4j navigator. Looking at why it was so slow, it became clear that the problem was that throughout jaxen it's building lists of intermediate results to filter down, instead of generating the 'next' result on demand. There's comments about this in several places in the code, but the list thing is so ingrained it needs more than a little refactoring to fix.
> I decided to have a go. This change produces apis incompatible with previous versions of jaxen, so this will be a lump of code not a wee patch. I've basically cloned jaxen to 'org.jaxen2' to work on it. I'm nearly done with the changes, failing tests for the non-xpath extension functions which I havent implemented yet, patterns (not touched at all yet), and a couple of minor bugs.
> I'll post the code on jira once I'm done, but here's the gist of the changes I made:
> - Introduce a Nodeset abstraction instead of a list...
> public interface extends Iterator {
> Object current();
> int position();
> // use of last() replaces the internal iterator with an iterator over a list caching results.
> // it's basically a fallback on what jaxen used to do.
> int last();
> }
> the reason for this is obvious, eg you can just test 'hasNext()' to check the boolean value of a nodeset.
> - change the signature of Expr to allow the selection of a fast code path
> public interface Expr {
> // these require context because of variable/function refs only. see later.
> boolean isBoolean(Context ctx);
> boolean isNumber(Context ctx);
> boolean isString(Context ctx);
> boolean isNodeset(Context ctx);
> boolean booleanValue(Context ctx);
> double numberValue(Context ctx);
> String stringValue(Context ctx);
> Nodeset nodesetValue(Context ctx);
> // etc
> }
> this is really for my own sanity as there's so much code to maintain. Throughout jaxen, everything is untyped, so its fairly easy to (eg) pass a nodeSet when you meant to pass a node; there's instanceof checks, == null checks, and casts everywhere to deal with this. Once you put everything behind an interface like the one above, making objects responsible for their own casts, a lot of the code is simplified, eg addition is just expr1.numberValue(ctx) + expr2.numberValue(ctx). All but a couple of classes inherit from abstract base classes that implement all but one of those methods (eg StringExprBase leaves stringValue() abstract.)
> Variable/Function refs don't have a type without context in my version, and like Jaxen I look up functions, variables every time. This isn't smart - in xpath we can resolve all variable, function refs beforehand, and get faster code as a result. I'll probably change things so I have 'bound' and 'unbound' exprs, add 'BoundExpr bind(VariableContext,FunctionContext)'. I'll still need to pass these as members of Context to support the 'evaluate' extension function though.
> Another approach to the same concern that I didn't try is to pass in a typed context, eg 'StringContext', 'NodesetContext', etc (think of this as allowing things like perl's 'wantarray()'. That approach would make it easier to expand the number of supported types (eg for xpath2) in future, I'll try it once the tests pass.
> - moved all the functions to a single utility class
> public class Functions {
> String substring(String s, double start, double end);
> // etc
> }
> this makes it easier to unit test the xpath functions, since they are mostly context-independent. Functions that need a navigator get it passed as the first arg, functions that optionally use the context node instead of an argument have that function added as a method of Context. Incidentally I changed some of the unit tests to get mine to pass - in particular I changed the substring() tests back to match the spec (they don't currently).
> No function in my version returns null. (compare to eg the name, namespaceuri functions of Navigator). The xpath spec uses "" or an empty nodeset throughout, so do I, this gets rid of a lot of == null checks.
> Some of the bugs against the current version of jaxen are fixed by this code - eg the use of double throughout allows gt/lt comparisons of longs (bug jaxen-28), + both of the bugs I filed previously.
> I'd estimate I can finish this in the next week.

From forum: jaxen - dev

[jira] Updated: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-16T10:16:35Z

[ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksander Adamowski updated JAXEN-31:
--------------------------------------

Attachment: Brian_Ewins_JAXEN-31_perf.patch

I've contacted Brian and he has prepared a cleaned up version of the patch with minimized differences (now it's only 30 kb).

I'll be working on it, but just in case I'm attaching it here.

The patch shouldn't break API compatibility (modulo some issues left to iron out) and Brian has just recently fixed some issues with it:
* off-by-one error in PredicateSet
* sort and reverse support in DefaultLocationPath

Additional notes from Brian:

"In one case I just added an ArrayList wrapper which is a bit wasteful, to make the sort work I implemented a load more methods in LazyList

the tests that are failing are: testUnboundNamespaceUsedInXPathExpression - this is likely to be because the test no longer triggers. There is code in BaseXpath now that unwraps some JaxenRuntimeExceptions, which was actually supposed to catch this test. Not sure why its not firing now. However, this test is only failing on illegal xpaths anyway - not a high priority

testPrecedingAxisInDocumentOrder - this one should have been fixed by the sort() mentioned above.

testIdentitySetUsageInDefaultNameStep - seems to be some issue with the way I'm uniquing the nodes after finding them. (there is a uniqueness check, but obviously its not working)

testAncestorAxis, testPrecedingSiblingAxisIsInDocumentOrder,testPrecedingAxisIsInDocumentOrder,testAncestorOrSelfAxis - all to do with the sort order of nodes.

I think the rest of the 21 are all dupes of these

The kind of thing that is supposed to be much faster with this, btw, is doing things like boolean(//x) - which tests for the existence of a node in the entire tree. Since this just involves forward axes, the lazy-list version will stop when it hits the first matching node, rather than continuing to accumulate node-sets. There's some overhead, reverse-axis tests may be slower, count() and the like which require collection of all nodes are likely to be unaffected."

> if jaxen stopped using lists it would be 37x faster
> ---------------------------------------------------
>
> Key: JAXEN-31
> URL: http://jira.codehaus.org/browse/JAXEN-31
> Project: jaxen
> Issue Type: Improvement
> Affects Versions: 1.0
> Reporter: Brian Ewins
> Fix For: 2.0
>
> Attachments: Brian_Ewins_JAXEN-31_perf.patch, jaxen.zip, stuff.tgz
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> The short story - I've rewritten jaxen to use a nodeset abstraction instead of a list to accumulate results. With the unit tests at nearly 100%, the performance test on dom4j runs in ~200ms on my 1GHz powerbook, compared to ~7400ms for the nightly jaxen build. The failing unit tests are for paths not covered in the performance test.
> The long story - I wrote an implementation of the draft ISO Schematron spec on top of Jaxen, instead of the more usual XSLT. The schematron spec is designed so this can be done, mainly for performance reasons. Once I had enough working I was able to compare jaxen with xalan on the 'screamatron' torture test, which is using schematron to validate the schematron 1.5 spec. I was suprised to find that jaxen was about 2x /slower/ than xalan, and marginally slower with a jdom navigator than a dom4j navigator. Looking at why it was so slow, it became clear that the problem was that throughout jaxen it's building lists of intermediate results to filter down, instead of generating the 'next' result on demand. There's comments about this in several places in the code, but the list thing is so ingrained it needs more than a little refactoring to fix.
> I decided to have a go. This change produces apis incompatible with previous versions of jaxen, so this will be a lump of code not a wee patch. I've basically cloned jaxen to 'org.jaxen2' to work on it. I'm nearly done with the changes, failing tests for the non-xpath extension functions which I havent implemented yet, patterns (not touched at all yet), and a couple of minor bugs.
> I'll post the code on jira once I'm done, but here's the gist of the changes I made:
> - Introduce a Nodeset abstraction instead of a list...
> public interface extends Iterator {
> Object current();
> int position();
> // use of last() replaces the internal iterator with an iterator over a list caching results.
> // it's basically a fallback on what jaxen used to do.
> int last();
> }
> the reason for this is obvious, eg you can just test 'hasNext()' to check the boolean value of a nodeset.
> - change the signature of Expr to allow the selection of a fast code path
> public interface Expr {
> // these require context because of variable/function refs only. see later.
> boolean isBoolean(Context ctx);
> boolean isNumber(Context ctx);
> boolean isString(Context ctx);
> boolean isNodeset(Context ctx);
> boolean booleanValue(Context ctx);
> double numberValue(Context ctx);
> String stringValue(Context ctx);
> Nodeset nodesetValue(Context ctx);
> // etc
> }
> this is really for my own sanity as there's so much code to maintain. Throughout jaxen, everything is untyped, so its fairly easy to (eg) pass a nodeSet when you meant to pass a node; there's instanceof checks, == null checks, and casts everywhere to deal with this. Once you put everything behind an interface like the one above, making objects responsible for their own casts, a lot of the code is simplified, eg addition is just expr1.numberValue(ctx) + expr2.numberValue(ctx). All but a couple of classes inherit from abstract base classes that implement all but one of those methods (eg StringExprBase leaves stringValue() abstract.)
> Variable/Function refs don't have a type without context in my version, and like Jaxen I look up functions, variables every time. This isn't smart - in xpath we can resolve all variable, function refs beforehand, and get faster code as a result. I'll probably change things so I have 'bound' and 'unbound' exprs, add 'BoundExpr bind(VariableContext,FunctionContext)'. I'll still need to pass these as members of Context to support the 'evaluate' extension function though.
> Another approach to the same concern that I didn't try is to pass in a typed context, eg 'StringContext', 'NodesetContext', etc (think of this as allowing things like perl's 'wantarray()'. That approach would make it easier to expand the number of supported types (eg for xpath2) in future, I'll try it once the tests pass.
> - moved all the functions to a single utility class
> public class Functions {
> String substring(String s, double start, double end);
> // etc
> }
> this makes it easier to unit test the xpath functions, since they are mostly context-independent. Functions that need a navigator get it passed as the first arg, functions that optionally use the context node instead of an argument have that function added as a method of Context. Incidentally I changed some of the unit tests to get mine to pass - in particular I changed the substring() tests back to match the spec (they don't currently).
> No function in my version returns null. (compare to eg the name, namespaceuri functions of Navigator). The xpath spec uses "" or an empty nodeset throughout, so do I, this gets rid of a lot of == null checks.
> Some of the bugs against the current version of jaxen are fixed by this code - eg the use of double throughout allows gt/lt comparisons of longs (bug jaxen-28), + both of the bugs I filed previously.
> I'd estimate I can finish this in the next week.

From forum: jaxen - dev

[jira] Commented: (JAXEN-205) Accidental subtree copy on the SVN trunk?

2009-10-15T09:45:26Z

[ http://jira.codehaus.org/browse/JAXEN-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194880#action_194880 ]

Brian Ewins commented on JAXEN-205:
-----------------------------------

Looks like this happened accidentally in the creation of r1340 "V1_1_2_Final". I checked and there's no differences between the extra 'jaxen' folder and its parent (other than the extra jaxen folder of course). So it can be safely deleted.

> Accidental subtree copy on the SVN trunk?
> -----------------------------------------
>
> Key: JAXEN-205
> URL: http://jira.codehaus.org/browse/JAXEN-205
> Project: jaxen
> Issue Type: Task
> Components: Build
> Reporter: Aleksander Adamowski
>
> In the SVN repository, one can see that the Jaxen sources are duplicated inside themselves on the trunk:
> https://svn.codehaus.org/jaxen/trunk/jaxen/
> https://svn.codehaus.org/jaxen/trunk/jaxen/jaxen/
> This doesn't look like an intentional SVN branch and doesn't seem to make any sense.
> If they are indeed accidental, I suggest deleting them as they make diffs between tags/branches and the trunk very cumbersome (not to speak about GIT repositories of other developers).

From forum: jaxen - dev

[jira] Created: (JAXEN-205) Accidental subtree copy on the SVN trunk?

2009-10-15T04:00:26Z

Accidental subtree copy on the SVN trunk?
-----------------------------------------

Key: JAXEN-205
URL: http://jira.codehaus.org/browse/JAXEN-205
Project: jaxen
Issue Type: Task
Components: Build
Reporter: Aleksander Adamowski

In the SVN repository, one can see that the Jaxen sources are duplicated inside themselves on the trunk:

https://svn.codehaus.org/jaxen/trunk/jaxen/
https://svn.codehaus.org/jaxen/trunk/jaxen/jaxen/

This doesn't look like an intentional SVN branch and doesn't seem to make any sense.

If they are indeed accidental, I suggest deleting them as they make diffs between tags/branches and the trunk very cumbersome (not to speak about GIT repositories of other developers).

--
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

From forum: jaxen - dev

[jira] Commented: (JAXEN-149) Upgrade to Maven 2

2009-10-15T03:47:26Z

[ http://jira.codehaus.org/browse/JAXEN-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194837#action_194837 ]

Aleksander Adamowski commented on JAXEN-149:
--------------------------------------------

Notes about the supplied pom.xml:

1) I've changed the project version to 1.1.3-SNAPSHOT.
Non-snapshots version numbers should be only reserved for stable teleases (they should only occur on branches and tags in SVN, never in trunk).

2) Relevant dependency numbers, which were too old for the build to succeed, were corrected (these were: maven-cobertura-plugin, maven-findbugs-plugin)

3) All the unit tests seem to run fine:

Results :

Tests run: 694, Failures: 0, Errors: 0, Skipped: 0

[INFO] [jar:jar]
[INFO] Building jar: c:\projekty\3rdparty\jaxen\jaxen-SVN\target\jaxen-1.1.3-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing c:\projekty\3rdparty\jaxen\jaxen-SVN\target\jaxen-1.1.3-SNAPSHOT.jar to C:\Documents and Settings\aadamowski\.m2\repository\jaxen\jaxen\1.1.3-SNAPSHOT\jaxen-1.1.3-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7 seconds
[INFO] Finished at: Thu Oct 15 12:45:58 CEST 2009
[INFO] Final Memory: 29M/254M
[INFO] ------------------------------------------------------------------------

> Upgrade to Maven 2
> ------------------
>
> Key: JAXEN-149
> URL: http://jira.codehaus.org/browse/JAXEN-149
> Project: jaxen
> Issue Type: Task
> Components: Build
> Affects Versions: 1.1
> Reporter: Elliotte Rusty Harold
> Fix For: 1.1.3
>
> Attachments: jaxen-maven2-upgrade.patch, pom.xml
>
>
> One of these days we should move forward to Maven 2, but not for Jaxen 1.1.

From forum: jaxen - dev

[jira] Commented: (JAXEN-149) Upgrade to Maven 2

2009-10-15T03:42:26Z

[ http://jira.codehaus.org/browse/JAXEN-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194834#action_194834 ]

Aleksander Adamowski commented on JAXEN-149:
--------------------------------------------

I gave a shot at doing it automatically using maven-one-plugin:

mvn one:convert

The result is mostly OK, but some dependencies need to have their version numbers updated. The unit tests run all OK.

Attaching patch (which only covers the new pom.xml) and the raw pom.xml itself.

> Upgrade to Maven 2
> ------------------
>
> Key: JAXEN-149
> URL: http://jira.codehaus.org/browse/JAXEN-149
> Project: jaxen
> Issue Type: Task
> Components: Build
> Affects Versions: 1.1
> Reporter: Elliotte Rusty Harold
> Fix For: 1.1.3
>
> Attachments: jaxen-maven2-upgrade.patch, pom.xml
>
>
> One of these days we should move forward to Maven 2, but not for Jaxen 1.1.

From forum: jaxen - dev

[jira] Updated: (JAXEN-149) Upgrade to Maven 2

2009-10-15T03:42:26Z

> Upgrade to Maven 2
> ------------------
>
> Key: JAXEN-149
> URL: http://jira.codehaus.org/browse/JAXEN-149
> Project: jaxen
> Issue Type: Task
> Components: Build
> Affects Versions: 1.1
> Reporter: Elliotte Rusty Harold
> Fix For: 1.1.3
>
> Attachments: jaxen-maven2-upgrade.patch, pom.xml
>
>
> One of these days we should move forward to Maven 2, but not for Jaxen 1.1.

From forum: jaxen - dev

[jira] Updated: (JAXEN-149) Upgrade to Maven 2

2009-10-15T03:42:26Z

> Upgrade to Maven 2
> ------------------
>
> Key: JAXEN-149
> URL: http://jira.codehaus.org/browse/JAXEN-149
> Project: jaxen
> Issue Type: Task
> Components: Build
> Affects Versions: 1.1
> Reporter: Elliotte Rusty Harold
> Fix For: 1.1.3
>
> Attachments: jaxen-maven2-upgrade.patch, pom.xml
>
>
> One of these days we should move forward to Maven 2, but not for Jaxen 1.1.

From forum: jaxen - dev

[jira] Commented: (JAXEN-204) Project infrastructure: fix Mailman mailing lists

2009-10-14T04:03:28Z

[ http://jira.codehaus.org/browse/JAXEN-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194674#action_194674 ]

Elliotte Rusty Harold commented on JAXEN-204:
---------------------------------------------

Weird since that's still a codehaus.org URL. Anyone know how to fix this? Should we escalate to codehaus? Bob?

> Project infrastructure: fix Mailman mailing lists
> -------------------------------------------------
>
> Key: JAXEN-204
> URL: http://jira.codehaus.org/browse/JAXEN-204
> Project: jaxen
> Issue Type: Task
> Reporter: Aleksander Adamowski
>
> There are some problems with the project mailing lists:
> 1) Links to mailing list archives (http://jaxen.org/mail-lists.html) are dead - they lead to an expired domain (archive.jaxen.codehaus.org), so the user ends up on an ad-ridden domain auction page
> 2) Mail sent to the lists bounces:
> I've subscribed to the mailing list and received a confirmation, but after that my posts get rejected because "only subscribers may post":
> ===============
> Date: Mon, 12 Oct 2009 05:48:06 -0500
> From: xircles@...
> Reply-To: dev-owner@...
> To: aleksander.adamowski@...
> Message-Id: <4ad30966cd6f0_66024af0b5a8c4@...>
> Subject: [Codehaus] Subscription confirmation for dev@...
> Mime-Version: 1.0
> Content-Type: multipart/alternative;
> boundary=mimepart_4ad30966cf2c5_66024af0b5a9f6
> --mimepart_4ad30966cf2c5_66024af0b5a9f6
> Content-Type: text/plain; charset=utf-8
> Content-Transfer-Encoding: Quoted-printable
> Content-Disposition: inline
> Hello aleksander.adamowski@...
> You have successfully subscribed to dev@... using this ema=
> il address.
> Thanks,
> Codehaus Support
> Here's a later message that bounced:
> ===============
> Message-Id: <4ad31c2e.9115f10a.4222.6654SMTPIN_ADDED@...>
> Received: (qmail 9502 invoked for bounce); 12 Oct 2009 12:08:10 -0000
> Date: 12 Oct 2009 12:08:10 -0000
> From: MAILER-DAEMON@...
> To: aleksander.adamowski@...
> Subject: failure notice
> Hi. This is the qmail-send program at mail.codehaus.org.
> I'm afraid I wasn't able to deliver your message to the following addresses.
> This is a permanent error; I've given up. Sorry it didn't work out.
> <dev@...>:
> Sorry, only subscribers may post. If you are a subscriber, please
> forward this message to dev-owner@... to get your new
> address included. (#5.7.2)
> --- Below this line is a copy of the message.
> Return-Path: <aleksander.adamowski@...>
> Received: (qmail 9434 invoked by uid 89); 12 Oct 2009 12:08:03 -0000
> Received: from unknown (HELO mail-yw0-f198.google.com) (209.85.211.198)
> by mail.codehaus.org with SMTP; 12 Oct 2009 12:08:03 -0000
> Received: by ywh36 with SMTP id 36so9185363ywh.15
> for <dev@...>; Mon, 12 Oct 2009 05:08:05 -0700 (PDT)
> MIME-Version: 1.0
> Received: by 10.91.160.25 with SMTP id m25mr1593245ago.91.1255349285198; Mon,
> 12 Oct 2009 05:08:05 -0700 (PDT)
> From: Aleksander Adamowski <aleksander.adamowski@...>
> Date: Mon, 12 Oct 2009 14:07:45 +0200
> Message-ID: <1c690d740910120507v5317970ieaf2a7703a1ef2f6@...>
> Subject: Jaxen project maintenance/development?
> To: Jaxen Developers List <dev@...>
> Content-Type: text/plain; charset=UTF-8

From forum: jaxen - dev

[jira] Created: (JAXEN-204) Project infrastructure: fix Mailman mailing lists

2009-10-13T09:27:26Z

Project infrastructure: fix Mailman mailing lists
-------------------------------------------------

Key: JAXEN-204
URL: http://jira.codehaus.org/browse/JAXEN-204
Project: jaxen
Issue Type: Task
Reporter: Aleksander Adamowski

There are some problems with the project mailing lists:

1) Links to mailing list archives (http://jaxen.org/mail-lists.html) are dead - they lead to an expired domain (archive.jaxen.codehaus.org), so the user ends up on an ad-ridden domain auction page
2) Mail sent to the lists bounces:

I've subscribed to the mailing list and received a confirmation, but after that my posts get rejected because "only subscribers may post":

===============
Date: Mon, 12 Oct 2009 05:48:06 -0500
From: xircles@...
Reply-To: dev-owner@...
To: aleksander.adamowski@...
Message-Id: <4ad30966cd6f0_66024af0b5a8c4@...>
Subject: [Codehaus] Subscription confirmation for dev@...
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary=mimepart_4ad30966cf2c5_66024af0b5a9f6

--mimepart_4ad30966cf2c5_66024af0b5a9f6
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: Quoted-printable
Content-Disposition: inline

Hello aleksander.adamowski@...

You have successfully subscribed to dev@... using this ema=
il address.

Thanks,

Codehaus Support

Here's a later message that bounced:
===============
Message-Id: <4ad31c2e.9115f10a.4222.6654SMTPIN_ADDED@...>
Received: (qmail 9502 invoked for bounce); 12 Oct 2009 12:08:10 -0000
Date: 12 Oct 2009 12:08:10 -0000
From: MAILER-DAEMON@...
To: aleksander.adamowski@...
Subject: failure notice

Hi. This is the qmail-send program at mail.codehaus.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<dev@...>:
Sorry, only subscribers may post. If you are a subscriber, please
forward this message to dev-owner@... to get your new
address included. (#5.7.2)

--- Below this line is a copy of the message.

Return-Path: <aleksander.adamowski@...>
Received: (qmail 9434 invoked by uid 89); 12 Oct 2009 12:08:03 -0000
Received: from unknown (HELO mail-yw0-f198.google.com) (209.85.211.198)
by mail.codehaus.org with SMTP; 12 Oct 2009 12:08:03 -0000
Received: by ywh36 with SMTP id 36so9185363ywh.15
for <dev@...>; Mon, 12 Oct 2009 05:08:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.91.160.25 with SMTP id m25mr1593245ago.91.1255349285198; Mon,
12 Oct 2009 05:08:05 -0700 (PDT)
From: Aleksander Adamowski <aleksander.adamowski@...>
Date: Mon, 12 Oct 2009 14:07:45 +0200
Message-ID: <1c690d740910120507v5317970ieaf2a7703a1ef2f6@...>
Subject: Jaxen project maintenance/development?
To: Jaxen Developers List <dev@...>
Content-Type: text/plain; charset=UTF-8

--
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

From forum: jaxen - dev

[jira] Commented: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-12T06:17:27Z

[ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194400#action_194400 ]

Aleksander Adamowski commented on JAXEN-31:
-------------------------------------------

OK, I've dug out some old posts on jaxen-user made by Brian in Nov 2004:

http://markmail.org/message/fhl327jznaxw3fbp
http://markmail.org/message/c226vid7yaoofdfm

They sort of lay out the proposed course of action WRT optimizing Jaxen.

Do you agree with assertions presented there?

As I understand, none of this has happened and 1.1.1 and 1.1.2 releases were made in the mean time.
Do those plans need to be revised, then? Or are they more or less still correct?

> if jaxen stopped using lists it would be 37x faster
> ---------------------------------------------------
>
> Key: JAXEN-31
> URL: http://jira.codehaus.org/browse/JAXEN-31
> Project: jaxen
> Issue Type: Improvement
> Affects Versions: 1.0
> Reporter: Brian Ewins
> Fix For: 2.0
>
> Attachments: jaxen.zip, stuff.tgz
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> The short story - I've rewritten jaxen to use a nodeset abstraction instead of a list to accumulate results. With the unit tests at nearly 100%, the performance test on dom4j runs in ~200ms on my 1GHz powerbook, compared to ~7400ms for the nightly jaxen build. The failing unit tests are for paths not covered in the performance test.
> The long story - I wrote an implementation of the draft ISO Schematron spec on top of Jaxen, instead of the more usual XSLT. The schematron spec is designed so this can be done, mainly for performance reasons. Once I had enough working I was able to compare jaxen with xalan on the 'screamatron' torture test, which is using schematron to validate the schematron 1.5 spec. I was suprised to find that jaxen was about 2x /slower/ than xalan, and marginally slower with a jdom navigator than a dom4j navigator. Looking at why it was so slow, it became clear that the problem was that throughout jaxen it's building lists of intermediate results to filter down, instead of generating the 'next' result on demand. There's comments about this in several places in the code, but the list thing is so ingrained it needs more than a little refactoring to fix.
> I decided to have a go. This change produces apis incompatible with previous versions of jaxen, so this will be a lump of code not a wee patch. I've basically cloned jaxen to 'org.jaxen2' to work on it. I'm nearly done with the changes, failing tests for the non-xpath extension functions which I havent implemented yet, patterns (not touched at all yet), and a couple of minor bugs.
> I'll post the code on jira once I'm done, but here's the gist of the changes I made:
> - Introduce a Nodeset abstraction instead of a list...
> public interface extends Iterator {
> Object current();
> int position();
> // use of last() replaces the internal iterator with an iterator over a list caching results.
> // it's basically a fallback on what jaxen used to do.
> int last();
> }
> the reason for this is obvious, eg you can just test 'hasNext()' to check the boolean value of a nodeset.
> - change the signature of Expr to allow the selection of a fast code path
> public interface Expr {
> // these require context because of variable/function refs only. see later.
> boolean isBoolean(Context ctx);
> boolean isNumber(Context ctx);
> boolean isString(Context ctx);
> boolean isNodeset(Context ctx);
> boolean booleanValue(Context ctx);
> double numberValue(Context ctx);
> String stringValue(Context ctx);
> Nodeset nodesetValue(Context ctx);
> // etc
> }
> this is really for my own sanity as there's so much code to maintain. Throughout jaxen, everything is untyped, so its fairly easy to (eg) pass a nodeSet when you meant to pass a node; there's instanceof checks, == null checks, and casts everywhere to deal with this. Once you put everything behind an interface like the one above, making objects responsible for their own casts, a lot of the code is simplified, eg addition is just expr1.numberValue(ctx) + expr2.numberValue(ctx). All but a couple of classes inherit from abstract base classes that implement all but one of those methods (eg StringExprBase leaves stringValue() abstract.)
> Variable/Function refs don't have a type without context in my version, and like Jaxen I look up functions, variables every time. This isn't smart - in xpath we can resolve all variable, function refs beforehand, and get faster code as a result. I'll probably change things so I have 'bound' and 'unbound' exprs, add 'BoundExpr bind(VariableContext,FunctionContext)'. I'll still need to pass these as members of Context to support the 'evaluate' extension function though.
> Another approach to the same concern that I didn't try is to pass in a typed context, eg 'StringContext', 'NodesetContext', etc (think of this as allowing things like perl's 'wantarray()'. That approach would make it easier to expand the number of supported types (eg for xpath2) in future, I'll try it once the tests pass.
> - moved all the functions to a single utility class
> public class Functions {
> String substring(String s, double start, double end);
> // etc
> }
> this makes it easier to unit test the xpath functions, since they are mostly context-independent. Functions that need a navigator get it passed as the first arg, functions that optionally use the context node instead of an argument have that function added as a method of Context. Incidentally I changed some of the unit tests to get mine to pass - in particular I changed the substring() tests back to match the spec (they don't currently).
> No function in my version returns null. (compare to eg the name, namespaceuri functions of Navigator). The xpath spec uses "" or an empty nodeset throughout, so do I, this gets rid of a lot of == null checks.
> Some of the bugs against the current version of jaxen are fixed by this code - eg the use of double throughout allows gt/lt comparisons of longs (bug jaxen-28), + both of the bugs I filed previously.
> I'd estimate I can finish this in the next week.

From forum: jaxen - dev

[jira] Commented: (JAXEN-31) if jaxen stopped using lists it would be 37x faster

2009-10-12T05:04:26Z

[ http://jira.codehaus.org/browse/JAXEN-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194390#action_194390 ]

Elliotte Rusty Harold commented on JAXEN-31:
--------------------------------------------

FYI, the tests you cite were run with Jaxen 1.0. This is years out of date. Since then, a lot of work has gone into both conformance and optimization so we likely do better now. I'd be curious to see updated results.

That said, the optimization suggested here may still be a good idea. As far as API compatibility, just make sure you don't change any existing public or protected class or method signatures, and you should be good. And of course the unti tests should all pass too.

> if jaxen stopped using lists it would be 37x faster
> ---------------------------------------------------
>
> Key: JAXEN-31
> URL: http://jira.codehaus.org/browse/JAXEN-31
> Project: jaxen
> Issue Type: Improvement
> Affects Versions: 1.0
> Reporter: Brian Ewins
> Fix For: 2.0
>
> Attachments: jaxen.zip, stuff.tgz
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> The short story - I've rewritten jaxen to use a nodeset abstraction instead of a list to accumulate results. With the unit tests at nearly 100%, the performance test on dom4j runs in ~200ms on my 1GHz powerbook, compared to ~7400ms for the nightly jaxen build. The failing unit tests are for paths not covered in the performance test.
> The long story - I wrote an implementation of the draft ISO Schematron spec on top of Jaxen, instead of the more usual XSLT. The schematron spec is designed so this can be done, mainly for performance reasons. Once I had enough working I was able to compare jaxen with xalan on the 'screamatron' torture test, which is using schematron to validate the schematron 1.5 spec. I was suprised to find that jaxen was about 2x /slower/ than xalan, and marginally slower with a jdom navigator than a dom4j navigator. Looking at why it was so slow, it became clear that the problem was that throughout jaxen it's building lists of intermediate results to filter down, instead of generating the 'next' result on demand. There's comments about this in several places in the code, but the list thing is so ingrained it needs more than a little refactoring to fix.
> I decided to have a go. This change produces apis incompatible with previous versions of jaxen, so this will be a lump of code not a wee patch. I've basically cloned jaxen to 'org.jaxen2' to work on it. I'm nearly done with the changes, failing tests for the non-xpath extension functions which I havent implemented yet, patterns (not touched at all yet), and a couple of minor bugs.
> I'll post the code on jira once I'm done, but here's the gist of the changes I made:
> - Introduce a Nodeset abstraction instead of a list...
> public interface extends Iterator {
> Object current();
> int position();
> // use of last() replaces the internal iterator with an iterator over a list caching results.
> // it's basically a fallback on what jaxen used to do.
> int last();
> }
> the reason for this is obvious, eg you can just test 'hasNext()' to check the boolean value of a nodeset.
> - change the signature of Expr to allow the selection of a fast code path
> public interface Expr {
> // these require context because of variable/function refs only. see later.
> boolean isBoolean(Context ctx);
> boolean isNumber(Context ctx);
> boolean isString(Context ctx);
> boolean isNodeset(Context ctx);
> boolean booleanValue(Context ctx);
> double numberValue(Context ctx);
> String stringValue(Context ctx);
> Nodeset nodesetValue(Context ctx);
> // etc
> }
> this is really for my own sanity as there's so much code to maintain. Throughout jaxen, everything is untyped, so its fairly easy to (eg) pass a nodeSet when you meant to pass a node; there's instanceof checks, == null checks, and casts everywhere to deal with this. Once you put everything behind an interface like the one above, making objects responsible for their own casts, a lot of the code is simplified, eg addition is just expr1.numberValue(ctx) + expr2.numberValue(ctx). All but a couple of classes inherit from abstract base classes that implement all but one of those methods (eg StringExprBase leaves stringValue() abstract.)
> Variable/Function refs don't have a type without context in my version, and like Jaxen I look up functions, variables every time. This isn't smart - in xpath we can resolve all variable, function refs beforehand, and get faster code as a result. I'll probably change things so I have 'bound' and 'unbound' exprs, add 'BoundExpr bind(VariableContext,FunctionContext)'. I'll still need to pass these as members of Context to support the 'evaluate' extension function though.
> Another approach to the same concern that I didn't try is to pass in a typed context, eg 'StringContext', 'NodesetContext', etc (think of this as allowing things like perl's 'wantarray()'. That approach would make it easier to expand the number of supported types (eg for xpath2) in future, I'll try it once the tests pass.
> - moved all the functions to a single utility class
> public class Functions {
> String substring(String s, double start, double end);
> // etc
> }
> this makes it easier to unit test the xpath functions, since they are mostly context-independent. Functions that need a navigator get it passed as the first arg, functions that optionally use the context node instead of an argument have that function added as a method of Context. Incidentally I changed some of the unit tests to get mine to pass - in particular I changed the substring() tests back to match the spec (they don't currently).
> No function in my version returns null. (compare to eg the name, namespaceuri functions of Navigator). The xpath spec uses "" or an empty nodeset throughout, so do I, this gets rid of a lot of == null checks.
> Some of the bugs against the current version of jaxen are fixed by this code - eg the use of double throughout allows gt/lt comparisons of longs (bug jaxen-28), + both of the bugs I filed previously.
> I'd estimate I can finish this in the next week.

From forum: jaxen - dev