[xslt] speedup for node document order



  It was a couple of months ago IIRC:
  I don't remember if it was Mark or someone else who had troubles
with the cost associated to sorting large nodeset in XPath. Ideally
an node counter could do this but there is no such thing in the existing
structure ... except I realized I usually keep line numbers from the
input on element nodes, and that could be used to at least help the sort
in most cases. The following patch does this it doesn't break the
regression tests (one need to recompile libxml, then libxslt
and make sure the parser generate the line numbers like xsltproc does
with xmlLineNumbersDefault(1); ).
  Whoever was having the problem, if you're still around I would like
comment on this patch,

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Index: xpath.c
===================================================================
RCS file: /cvs/gnome/gnome-xml/xpath.c,v
retrieving revision 1.206
diff -c -r1.206 xpath.c
*** xpath.c	22 Oct 2002 17:35:33 -0000	1.206
--- xpath.c	7 Nov 2002 22:44:39 -0000
***************
*** 1368,1373 ****
--- 1368,1388 ----
  	return(-1);
  
      /*
+      * Speedup using line numbers if availble.
+      */
+     if ((node1->type == XML_ELEMENT_NODE) &&
+ 	(node2->type == XML_ELEMENT_NODE) &&
+ 	(0 != (int) node1->content) && (0 != (int) node2->content)) {
+ 	int l1, l2;
+ 	l1 = (int) node1->content;
+ 	l2 = (int) node2->content;
+ 	if (l1 < l2)
+ 	    return(1);
+ 	if (l1 > l2)
+ 	    return(-1);
+     }
+ 
+     /*
       * compute depth to root
       */
      for (depth2 = 0, cur = node2;cur->parent != NULL;cur = cur->parent) {


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