[xml] optimizing patch for xpath.c



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]