At least, fixed!!!!!!!!!!!!!!!!!
It was driving me mad.  I was thinking of  saying: OK, I have do test
with hundreds of XML files, and the  1.2 approach was speedier than
the 1.1 approach, but your test is clear and we need to throw all the
1.2 version and begin with the 1.1 and tar myself, and wear a paper
bag over the head all my life.

But, I'd found the error after using jrat profiler: your test was only
spending 6% of the time in the xml-sec code, the rest was spent
somewhere else, and that place was toByteArray() inside
ByteArrayOutputStream. So with this date I made my simple
OwnByteArrayOutputStream, and  no matter how big I made the byte array
I always got an OutOfBounds exception. Then I remember that I made
some changes in order to reduce memory consumption that avoids the
reuse of canocilizer as it does not reset the ByteArrayOS. I'll fix
this problem(one line change) and I got  these new figures:

Your test case, in my machine:
using 1.1:  1116 ms
using CVS HEAD: 341 ms

A nice improvement, isn't it?

You can test your self obtaining & compiling the CVS HEAD version
library or just changing your test to not reuse Canonicalizer object.

Regards,

Raul
http://r-bg.com

p.s. Before finding the error, I was thinking that the
NameSpaceSymbTable was the main culprit of the slow down. And I was
thinking in rewriting it in order to not use HashMap and use a simple
String[], it will improve the things if there are few concurrent
different prefix mappings.
Has anybody found more than 10 xmlns:prefix mappings in a document?????? 
I haven't, but I don't know. So please share your knoledge.





On Tue, 18 Jan 2005 11:14:15 +0500, Egor Pervuninski <[EMAIL PROTECTED]> wrote:
> Hello Raul,
> 
> I am using Microsoft Windows 2000 Professional 5.00.2195 with
> ServicePack 4 and "Russian" locale.
> I have Celeron 1200MHz machine with 512Mb RAM.
> 
> I have tried to run java with -server option using two different JREs
> but results were the same.
> 
> Here is the output of java -version for j2sdk 1.5.0:
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64)
> Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode)
> 
> Results with -client:
> 1.1: time spent 921 ms
> 1.2: time spent 27710 ms
> Results with -server:
> 1.1: time spent 2374 ms
> 1.2: time spent 26438 ms
> 
> Here is the output of java -version for j2sdk 1.4.2:
> java version "1.4.2_03"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
> Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)
> 
> Results with -client:
> 1.1: time spent 901 ms
> 1.2: time spent 23014 ms
> Results with -server:
> 1.1: time spent 2013 ms
> 1.2: time spent 23014 ms
> 
> I will try to profile the library in my spare time and post the result.
> 
> Regards,
> Egor Pervuninski
> egor {dot} pervuninski {at} gmail {dot} com
> 
> Raul Benito wrote:
> 
> >Hi Egor,
> >
> >
> >  First of all sorry for not answering your request sooner. Regarding
> >your problem, it seems that the way we transform the stream to UTF8 in
> >1.2(the library do the conversion itself) is slower in your case to
> >the way it was done 1.1(we use classes given by the SDK). This is
> >weird because, I made a lot of test regarding it and was always faster
> >doing in the library that letting the work for the API. I will
> >investigate this a little more, but IŽll need more information
> >regarding your runtime: What JRE are you using, in what OS, in what
> >locale, and of course are you testing with JIT enable(i.e. are you
> >using -server or -client).
> >
> >Regards,
> >
> >Raul
> >http://r-bg.com
> >
> >On Tue, 11 Jan 2005 18:38:40 +0500, Egor Pervuninski <[EMAIL PROTECTED]> 
> >wrote:
> >
> >
> >>Hello,
> >>
> >>Sure, here it is.
> >>
> >>## Davanum Srinivas : Tue, 11 Jan 2005 08:28:24 -0500
> >>
> >>DS>  Can you please post your test.xml as well?  thanks, dims
> >>DS>
> >>DS> On Tue, 11 Jan 2005 18:31:18 +0500, Egor Pervuninski
> >>DS> <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >>>>Hello,
> >>>>
> >>>>Recently I tried to upgrade my project to use new Apache XML
> >>>>Security 1.2 for Java and found that now the library does c14n much
> >>>>MUCH more slowly than it was with 1.1.
> >>>>
> >>>>Here is a simple test:
> >>>>
> >>>>import javax.xml.parsers.DocumentBuilder; import
> >>>>javax.xml.parsers.DocumentBuilderFactory;
> >>>>
> >>>>import org.apache.commons.lang.time.StopWatch; import
> >>>>org.apache.xml.security.c14n.Canonicalizer; import
> >>>>org.w3c.dom.Document; import org.xml.sax.InputSource;
> >>>>
> >>>>public class Test { private final static int REPEAT = 1000;
> >>>>
> >>>>private StopWatch timer = new StopWatch(); private Canonicalizer
> >>>>canon =
> >>>>Canonicalizer.getInstance(Canonicalizer.ALGO_ID_C14N_OMIT_COMMENTS);
> >>>>private Document document;
> >>>>
> >>>>public Test(String file) throws Exception { DocumentBuilderFactory
> >>>>factory = DocumentBuilderFactory.newInstance();
> >>>>factory.setNamespaceAware(true); factory.setValidating(false);
> >>>>DocumentBuilder builder = factory.newDocumentBuilder(); document =
> >>>>builder.parse(new InputSource(file)); }
> >>>>
> >>>>public void runTest() throws Exception { timer.start(); for (int i
> >>>>= 0; i < REPEAT; i++) { canon.canonicalizeSubtree(document); }
> >>>>timer.stop(); System.out.println("time spent " +
> >>>>String.valueOf(timer.getTime()) + " ms"); }
> >>>>
> >>>>public static void main(String[] args) throws Exception {
> >>>>org.apache.xml.security.Init.init(); Test test = new Test(args[0]);
> >>>>test.runTest(); } }
> >>>>
> >>>>Just drop commons-lang-2.0.jar, commons-logging.jar,
> >>>>xercesImpl.jar, xml-apis.jar and xmlsec.jarto the classpath and run
> >>>>java Test File.xml.
> >>>>
> >>>>Version 1.1 output: time spent 952 ms Version 1.2 output: time
> >>>>spent 29172 ms
> >>>>
> >>>>Where is the catch?
> >>>>
> >>>>Regards, Egor Pervuninski egor {dot} pervuninski {at} gmail {dot}
> >>>>com
> >>>>
> >>>>
> >>>>
> >>DS> --
> >>DS> Davanum Srinivas - http://webservices.apache.org/~dims/
> >>DS>
> >>
> >>Regards,
> >>Egor Pervuninski
> >>egor {dot} pervuninski {at} gmail {dot} com
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> 
>

Reply via email to