Re: [Xmlunit-general] XPathContext.getXPath taking bulk of compare time

[Stefan B. <bo...@ap...>]

On 2013-04-11, David Rees wrote:

> On 4/11/13 1:06 PM, David Rees wrote:

>> I've actually tracked it down to two things in the XPathContext.getXPath.

>> The biggest is actually the "replace(SEP + SEP, SEP)". When I remove
>> that my XMLUnit benchmarks go from 0.11 to 0.06. I haven't played with
>> it enough yet to know enough about why that line is there so I can
>> replace it.

I don't recall under which circumstances it happens but there are
certain edge cases.  If you remove the line there should be failing unit
tests that should tell you why I introduced it.  Sorry, but I haven't
looked at the actual code for three years or so - and thank you for
working on it.

>> I also took a first crack at using dynamic programming to store the
>> xpath expression in the Level objects. So its only computed once for
>> each level. That took it from 0.06 to 0.04. A patch with that first
>> crack is at https://sourceforge.net/p/xmlunit/bugs/61/.

I'll look into it later this weekend.

> Actually, since the Comparison has the nodes themselves can't it just
> compute the xpath using them (on demand)? Are there cases where this
> wouldn't work?

TBH I modeled this after the XMLUnit 1.x difference engine which
calculates the XPath while walking the tree as well and never questioned
that design.  The trickies part would be knowing the sibblings on each
level (what to put into the sqare brackets of /foo/bar[...]/baz on the
XPath of a baz element) - this might benefit from some caching as you
suggest to do for Level instances.

Stefan