On 11/27/05, Werner Dittmann <[EMAIL PROTECTED]> wrote: > Raul, > > thanks for the info. If I understood you correctly then the > performance problem is due to some specific Xpath/namespace > usage for xml-sec, not a generic XPath problem to locate > some elements in a document. > You are right, anyhow is usally slower to use xpath to select elements than using an Id, but the xml sec should only be a little slower because of this not a big slower as it is now.
> Background to this question: > some specifications (WS-SecurityPolicy) > use XPath to locate the elements to process (sign, encrypt). > > In case a SecurityPolicy defines a XPath I would use the XPath > to locate the element, insert a wsu:Id and use this id to add > the element to sign (as already done in WSS4J) thus avoiding any > XPath processing during signature > > Any ideas to that, caveats to look at? > That sounds good to me. But anyhow if there are more clients that need xpath, I can improve the performance of the slow path. And that is the main reoson for the beginig mail. To know what other people needs. So please, if you need a faster xpath in your signatures, raise your hands.... Regards, Raul > Regards, > Werner > > Raul Benito wrote: > > On 11/25/05, Werner Dittmann <[EMAIL PROTECTED]> wrote: > > > >>Raul, > >> > >>first of all thanks for the big imporvments you did for xmlsec !! > >> > >>With respect to performance: I'm just working on JuiCE to have > >>a JCE compliant provider for the main functions of OpenSSL. First > >>tests I did (using some modes inside BouncyCastle) were promising. > >>We're waiting for some Sun action (Certificate to produce a signed > >>JCE jar). > >> > > > > That will be good, > > Juice was the reason I'll begin to hack xml-sec: at 1.0.D2 times I > > thought the xml-sec problems was due slownes in JCE, but after seeing > > that juice speeds a lot digesting and signing but none xml-sec i begin > > to investigate inside xml-sec... > > > > I'll think that today it will speed xml-sec a lot.(well I have > > published some figures before with xmlbench). > > > > > >>Just a question about YPath: AFAIK XPath is implemented > >>in Xalan, what is the problem regarding performance here? Or is > >>this a problem of xmlsec using XPath? > >> > > > > The root of all problems can be traced to this infamous bug in xalan: > > http://issues.apache.org/bugzilla/show_bug.cgi?id=2650 > > In order to not be hit with this bug in xml-sec, when it c14ns any > > nodeset the XMLUtils.circumventBug2650 function is called. This method > > just visit all the nodes an copy/creates all the namespace bindings > > (the xmlns:*=... things), that contain all its ancestors. > > I'm sure you can see that this function is a very costly operatin > > both in time and memory(creating a lot attributtes of a DOM tree is > > not cheap). But it also increase further processing time (the c14n is > > mainly o(n) where n is the number of nodes that we have just manage to > > increase, in sometimes duplicate). > > So the xpath cannot handle big documents as it will make it bigger, > > in an exponential way( the bigger the number elements, the bigger of > > creation of new xmlns bindings). > > The main difference between 1.1 and 1.2 is the splitting of the slow > > path(the xpath) and the fast path(no xpath), and not use the > > XMLUtils.circumventBug2650 in the fast path. And you all can see that > > it pays off. > > The ironic of this problem is that the XMLUtils.circumventBug2650 is > > only seldom needed in the xpath(only when the xpath expression > > contains any namespace selection), so in theory we can check if > > XMLUtils.circumventBug2650 is needed and only in the small cases call > > it. > > But xml-sec nodeset c14n methods algorithm impose that its input has > > been "circumvented", and it does not work with no circumvented > > nodesets. This behaviour can be fixed (two weeks fully dedicated) but > > we are going to end with three c14n methods: > > - one for whole nodes. > > - one for NOT circumvented nodesets. > > - one for circumvented nodesets. > > The first two will be simillar > > > > All in All: the xpath path in xml-sec takes a hit becouse a bug in > > xalan, but this hit is avoidable with some work(three months of work > > with my current "free" time). > > > > I hope this email is readable enough. ;) > > > > Regards, > > > > Raul > > > >>Regards, > >>Werner > >> > >>PS: something that needs some "brush up" is the XMLCipher code, > >> > > > > You are right. So many things, so few time... > > > >>Werner > >> > >>Raul Benito wrote: > >> > >>>Hello Everybody, > >>> After the painful release of the xmlsec(mainly because of the > >>>updating of the web page, and deadlines in my "day" job), I begin to > >>>wonder where the java xml sec should lead. > >>> > >>>>From my area of expertise, performance: > >>> The fast path (URI selection, only enveloping transformation) is as > >>>fast as it can gets(about 10% overhead of plain serialization and > >>>digesting), it can only get better with JCE(70% of execution time) > >>>speed ups (Juice any one??). > >>> Anyhow perhaps is time to improve performance in the slow(xpath > >>>transformation) path. with a little help we can get rid off the slow > >>>circunventbug call. > >>> Or perhaps is better to pursue newer fields, I having playing with > >>>SAX and the results are impressive, documents that the DOM library can > >>>not ever dream manage the SAX handles without any memory adjustments, > >>>and fast as hell. > >>> But SAX is not the api of mode anymore perhaps is better to take a > >>>look Stax and begin to work on it. It seems that are more projects > >>>using Stax than sax nowadays (axis, xmlbeans,...). > >>> > >>>What do you think? Where we should focus our efforts performance wise???? > >>> > >>> > >>>And that's not all, jsr 105, the neglected encrypted part, xkms.... > >>>New transformations, c14ns, j2me, etc... But that's a discussion, for > >>>other thread. > >>> > >>>Regards, > >>> > >>>Raul > >>>-- > >>>http://r-bg.com > >>> > >> > >> > > > > > > -- > > http://r-bg.com > > > > -- http://r-bg.com