The exact changes are hard to define, there are a lot of micro optimizations for reducing the time of processing small signatures(<4k) the kind of signatures that stress xmlbench.
The main ones are pooling "costly" objects in threadlocal objects. And being as lazy as possible initializing so don't waste time if this fields are not needed.
All in All the speed-up in xmlbench is 40% better from 1.3(these are estimates, I'm far from my own computer).
So if you are in the procol business(saml/ws) this release should be better(10-20% in real terms).
Regarding StaX I have only begin the implementation and my main aim right now is to make it correct and easy to debug.It has a lot of very slow parts(Everything is using Strings and concat to it so it is easier to print). So I haven't do any performance test so far.
But I suposse that it will be more or less similar than the sax one (http://issues.apache.org/bugzilla/show_bug.cgi?id=32657 ), the bigger are the document the greater the performance gap between DOM & SAX/stax. (I've manage to verify documents with the sax document that were imposible to even load with DOM).
I want to keep working in the stax implementation and do a small benchmark comparing the time that the different implementations(apache c++/java library/ the JSR105/ STAX/ c libxml) takes verifying a SAML2.0 request with assertion. But this will take time, as I only do xml signature work in my spare time.
Anyway any feedback in the stax part will be welcome.
Regards,
The main ones are pooling "costly" objects in threadlocal objects. And being as lazy as possible initializing so don't waste time if this fields are not needed.
All in All the speed-up in xmlbench is 40% better from 1.3(these are estimates, I'm far from my own computer).
So if you are in the procol business(saml/ws) this release should be better(10-20% in real terms).
Regarding StaX I have only begin the implementation and my main aim right now is to make it correct and easy to debug.It has a lot of very slow parts(Everything is using Strings and concat to it so it is easier to print). So I haven't do any performance test so far.
But I suposse that it will be more or less similar than the sax one (http://issues.apache.org/bugzilla/show_bug.cgi?id=32657 ), the bigger are the document the greater the performance gap between DOM & SAX/stax. (I've manage to verify documents with the sax document that were imposible to even load with DOM).
I want to keep working in the stax implementation and do a small benchmark comparing the time that the different implementations(apache c++/java library/ the JSR105/ STAX/ c libxml) takes verifying a SAML2.0 request with assertion. But this will take time, as I only do xml signature work in my spare time.
Anyway any feedback in the stax part will be welcome.
Regards,
On 6/20/06,
Venu <[EMAIL PROTECTED]> wrote:
Hi Raul,
Can you point me to exact set of performance changes that have gone
in(It was hard to find from you blog , may be I din't take a closer
look :) ).
Do you have any performance numbers for the StAX implementation you have
incorporated.
Thanks in Advance,
Venu
Subject:
Apache XML Security Java Libray 1.4Beta0 release
From:
Raul Benito < [EMAIL PROTECTED]>
Date:
Mon, 19 Jun 2006 00:34:23 +0200
To:
[email protected]
Hi All,
I have just taged and uploaded the Apache XML Security Java Libray
1.4Beta0 release. You can find a simple jar in the following URL:
http://xml.apache.org/security/dist/java-library/xmlsec-1.4.Beta0.jar
The main changes are:
-JSR 105(thanks to Sean)
-Important bug fixes
-Performance optimizations(see http://r-bg.com/apache for more info).
-API changes for Transfrom & KeyResolver class(if you have a
implemantation of this classes out of the tree take these changes into
account)
-And last changes in thread behaviour.
As you see the changes can have negative impact in working code. So
please test it hard. And fill as many bug reports as you can.
Pleas don't make me make another 1.4.1 brown bag release.
Thanks.
Raul
--
http://r-bg.com
--
http://r-bg.com
