Re: Performace data and comparison

Hi Christian,

The proposed XPath filter is clear and intuitive and it
effectively and efficiently solves the problems that it sets
out to address. I think it might be a good idea to allow
multiple XPath children of the filter transform; that would
allow a sequence of steps to be logically grouped, and might
help implementers perform optimizations.

In my opinion, your labeling proposal lacks the clarity and
simplicity of the XPath filter and is not addressing a problem
that needs solving, based on my understanding of the needs
of current XML signature applications.

If the purpose of this transform was to solve the types of
problem that you are posing, then I would grant that a pure
set-based solution is not as efficient as possible, and that
your proposal would merit consideration.

However, that is not the purpose of this transform. Your
own data show that the current proposal is more efficient
than yours for *real-world* problems, which are the types of
problem that we need to solve.

Even if the performance tipped slightly the other way, I
think that set-based operations on subtrees are a much more
intuitive and accessible solution than yours, and so I would
still advocate them. If you can, as I have asked before,
produce a real-world problem that is badly solved by our
transform, then please present it. I do not count the
example below (yes, I've looked at it) as a real-world
problem. Otherwise, I think your own data show that we have
a good solution.

Merlin

r/geuer-pollmann@nue.et-inf.uni-siegen.de/2002.05.13/16:04:48
>--On Donnerstag, 9. Mai 2002 23:50 +0200 Christian Geuer-Pollmann 
><geuer-pollmann@nue.et-inf.uni-siegen.de> wrote:
>
>> When you look at the results below, you see that each step in the
>> xfilter2spec_xfilter2_(1/2/3) adds more processing time, while this is
>> not the case for 'my' transform: I can't tell why they are as they are.
>
>I constructed an obfuscated example in which I select some subtrees for 
>inclusion/exclusion. To get the final result, I must perform 7 xfilter2 
>transforms. Each transform adds more overhead. To test how much each 
>transform requires, I ran the test suite 10 times, while the first test 
>only did the 1st transform, the second test included the 1st and the 2nd 
>transform while the 7th test included all seven steps. The results are 
>shown below
>
>10 * apachesample_xfilter2_1     took  5,097 seconds
>10 * apachesample_xfilter2_2     took  5,879 seconds
>10 * apachesample_xfilter2_3     took  6,790 seconds
>10 * apachesample_xfilter2_4     took  7,290 seconds
>10 * apachesample_xfilter2_5     took  8,442 seconds
>10 * apachesample_xfilter2_6     took  9,503 seconds
>10 * apachesample_xfilter2_7     took 10,475 seconds
>
>You can see that the required time is strictly monotonic increasing for 
>each added transform step. To check that against my own algorithm, I write 
>7 transforms which achieve the same results as the corresponding xfilter2 
>ones:
>
>10 * apachesample_apachefilter_1 took  5,207 seconds
>10 * apachesample_apachefilter_2 took  5,638 seconds
>10 * apachesample_apachefilter_3 took  5,408 seconds
>10 * apachesample_apachefilter_4 took  5,478 seconds
>10 * apachesample_apachefilter_5 took  5,528 seconds
>10 * apachesample_apachefilter_6 took  5,508 seconds
>10 * apachesample_apachefilter_7 took  5,358 seconds
>
>You can  see that the time is -- well, not constant, but does not show this 
>heavy dependency to take longer for complexer selections.
>
>BTW, if you wanna check this yourself, the implementation of the transform 
>[1] is in the Apache CVS, the test suite also [2].
>
>Kind regards,
>Christian
>
>
>[1] 
><http://cvs.apache.org/viewcvs.cgi/xml-security/src/org/apache/xml/security
>/transforms/implementations/TransformXPathFilterCHGP.java?rev=1.2&content-t
>ype=text/vnd.viewcvs-markup>
>
>[2] 
><http://cvs.apache.org/viewcvs.cgi/xml-security/src_samples/org/apache/xml/
>security/samples/TransformPerformanceTester.java?rev=1.3&content-type=text/
>vnd.viewcvs-markup>
>


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com

Received on Monday, 13 May 2002 15:11:15 UTC