santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Benito <>
Subject Re: xmlsec 1.3 released... and now what's left.
Date Sat, 26 Nov 2005 11:30:10 GMT
On 11/25/05, Werner Dittmann <> 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:
  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
  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,
> 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
> > --
> >
> >


View raw message