On Fri, 2012-08-24 at 12:21 +0800, Daniel Veillard wrote:
[...]
I suspect it's just the top of the iceberg, there is a number of other
post-compilation optimization which can certainly be made, but with
less drastic improvements.
Mike Kay has spoken at I think XML Prague and/or Balisage about
When investigating the libxslt performance problem reported in bug
#657665, I found that '//' in XPath expressions can be very slow when
working on large subtrees.
One of the reasons is the seemingly quadratic time complexity of the
duplicate checks when merging result nodes. The other is a
Hi Nick,
On Sun, Aug 19, 2012 at 07:42:38PM +0200, Nick Wellnhofer wrote:
When investigating the libxslt performance problem reported in bug
#657665, I found that '//' in XPath expressions can be very slow
when working on large subtrees.
I guess everybody agree on that statement :-)
One
On Fri, 2012-08-24 at 12:21 +0800, Daniel Veillard wrote:
[...]
I suspect it's just the top of the iceberg, there is a number of other
post-compilation optimization which can certainly be made, but with
less drastic improvements.
Mike Kay has spoken at I think XML Prague and/or Balisage about
On Fri, Aug 24, 2012 at 12:47:16AM -0400, Liam R E Quin wrote:
On Fri, 2012-08-24 at 12:21 +0800, Daniel Veillard wrote:
[...]
I suspect it's just the top of the iceberg, there is a number of other
post-compilation optimization which can certainly be made, but with
less drastic
