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

[David R. <da...@ub...>]

Another approach to consider, in line with your thoughts, would be to 
teach XPathContext Level's their parents. Then you could just store the 
Level in the Comparison.

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?

d

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 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/.
>
> d
>
>
> On 4/11/13 11:59 AM, Stefan Bodewig wrote:
>> On 2013-04-06, David Rees wrote:
>>
>>> After running some profiling on my tests I've discovered that XMLUnit
>>> is taking the bulk of the time and XPathContext.getXPath is taking 58%
>>> of XMLUnit's time.
>> That's huge.
>>
>>> XPathContext.getXPath is called twice every time a comparison is done
>>> to add the xpath for the control and test value to the created
>>> Comparison. However, the xpath is only needed when the comparison
>>> fails or if match tracking is being done. Perhaps the Comparison
>>> should only be created if the compare fails or maybe the xpath should
>>> only be set when compare fails?
>> Are we talking 2.0 here?  Really, we've got a user :-)
>>
>> In that case this is not quite true.  DifferenceEvaluator is called for
>> each and every comparison and the implementation might base its decision
>> on the actual XPath.
>>
>> One option may be to somehow copy XPathContext's state into the
>> Comparison and evaluate it lazily only when the XPath needs to be
>> constructed.  This would require creating new objects with a copy of
>> XPathContext's "path" member rather than building up the string.  In the
>> end that may cause similar pressure on the garbage collector but should
>> be faster than building up the string (and running replace on it).
>>
>> Stefan
>