Hi, > -----Original Message----- > From: Martijn Faassen [mailto:[EMAIL PROTECTED] > Sent: Friday, June 09, 2006 1:00 PM > To: Buchcik, Kasimier > Cc: [EMAIL PROTECTED]; [email protected] > 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 [email protected], 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 _______________________________________________ xml mailing list, project page http://xmlsoft.org/ [email protected] http://mail.gnome.org/mailman/listinfo/xml
