RE: [xml] Release of libxml2-2.6.26

["Buchcik, Kasimier" <k buchcik 4commerce de>]

Hi,

> -----Original Message-----
> From: Martijn Faassen [mailto:faassen infrae com] 
> Sent: Friday, June 09, 2006 1:00 PM
> To: Buchcik, Kasimier
> Cc: veillard redhat com; xml gnome org
> Subject: Re: [xml] Release of libxml2-2.6.26
>
> Hey,
>
> > > * improvements:
> > >  - Xpath optimizations (Kasimier)
> > >  - XPath object cache(Kasimier)
>
> Is there a story on what kind of optimizations these are, what their 
> effect is in practice, and what an XPath object cache is? Kasimier? :)

The story began here:
http://mail.gnome.org/archives/xml/2006-May/msg00040.html

And then I moved it over to xslt gnome org, since I incorrectly
thought it was mainly a Libxslt problem:
http://mail.gnome.org/archives/xslt/2006-May/msg00055.html

Some bla about the enhancements also in:
http://mail.gnome.org/archives/xslt/2006-May/msg00074.html

1) Optimized xmlXPathCollectAndTest() to avoid massive
  creation/freeing of temporary node sets for every run over
  an axis.

2) For "//foo", i.e. for expressions which start with selecting
  the document node and then have a descendant-or-self::node()
  (but only the short-hand form "//" yet) node test and then
  have a child::foo node test, I added a compound traversal,
  which will traverse both the d-o-s and the child axis in one
  go.

3) Optimized the "[position() = 1]" predicate, but actually only the
  short-hand form "[1]", for predicates like in:
  "key('foo', 'bar')[parent::boo][1]"; this was already optimized for
  "key('foo', 'bar')[1]" - without the additional inner predicate.
  Libxml2 handles such predicates differently from predicates in e.g.
  "foo[parent::boo][1]", in the way that the former version is an
  XPATH_OP_FILTER and the latter an XPATH_OP_PREDICATE, both with
  slightly different AST structures. Both are currently evaluated in
  xmlXPathCompOpEval[First]().
  This is also related to:
  http://mail.gnome.org/archives/xml/2006-June/msg00005.html , where
  I realized that "foo[parent::boo][1]" still needs to be optimized
  (its an XPATH_OP_PREDICATE). I already have an optimization for
  this ready, but want to wait a but until the current release feels
  good enough.

4) If enabled the cache will cache XPath objects, so they
  can be reused internally (only internally; there's no public API
  for this). This results in less memory mess; e.g. for
  boolean objects, which are often used just to indicate a "true"
  XPath result.
  The cache is disabled if you create a fresh XPath context;
  enable/disable this with xmlXPathContextSetCache().
  The cache is enabled now by default for Libxslt.

5) Optimized xsl:key/key() in Libxslt. All keys were calculated for all
 input documents at the beginning of the transformation and
 if a new document came as input. This is now done on-demand, so
 if a specific key is never called for a specific document, then
 this specific key is never calculated for this specific document.
 This reduces memory usage, and increases performance if not
 all keys are used on all input documents.


Tip: Try to reuse the xmlXPathContext as much as possible; 
Jerome Pesenti noticed that in Libxslt, massive creation/freeing of this
context struct is a bottleneck during the compilation of stylesheets.
That's why it is kept now for reusal on the compilation context in the
refactored code of Libxslt.

Regards,

Kasimier