-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Daniel, All, xmlXPathOrderDocElems optimises XPath to some extend by indexing elements. This optimisation is however only used when document-order of elements is computed. Yet it can be useful for other nodes as well, because unless they belong to the same element, their document order is computed from their ancestors which in turn can again be elements and can therefore be optimised. The attached simple copy/paste patch for xpath.c applies the optimisation again as soon as the highest non-common ancestor elements for the compared nodes are found. The results are quite surprising: before optimisation: pajas$ time xsh -I 3.xml 'index .; count //node()' parsing 3.xml done. indexing XML::LibXML::Document=SCALAR(0x946b788) at 1:8 (char 7) 140034 elements indexed. 361728 nodes real 0m52.783s user 0m50.830s sys 0m0.230s after optimisation: pajas$ time xsh -I 3.xml 'index .; count //node()' parsing 3.xml done. indexing XML::LibXML::Document=SCALAR(0x95025b0) at 1:8 (char 7) 140034 elements indexed. 361728 real 0m7.696s user 0m7.290s sys 0m0.180s Of course, if the document contained only elements, there would be little difference, if any at all. /Petr
Attachment:
xpath.diff
Description: Text Data
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFAMfqCQfxdLDi03+IRAv3CAJ41oWUtNz0qaWHNEUvcCB17sVd9cwCgodmM Tllt2LdL8mi91RpH7pTjqFE= =FF5O -----END PGP SIGNATURE-----