Re: AW: [xml] extremely long xslt transformation times

On Mon, Sep 30, 2002 at 03:36:20PM +0200, Steinborn Thomas wrote:
  2 sounds impossible technically, I don't want to change the format
of the in-memory representation. 1 and 3 are okay at an architectural
level but I don't see how to do this easilly in practice. But if you
know how to do this, feel free to work on it, I take patches !

Okay, so if the UNION operator sorts the result set that top level 
sort is not needed, right?

  no, precisely because the UNION does not sort.

What about COLLECTS, they deliver sorted results as well? If so, maybe we
can optimize more?

  They do only if you have a single initial node. If you have
a set of nodes as input you get an aggregation of sorted sublists.
And the sort is always dependant on the axis some are forward,
others backward (and some return at most an unique value).

  If it was simple I would have done that optimization, some optimizations
are certainly possible, but I didn't try to work in the sorting area.


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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