cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Sahuc <ssa...@imediation.com>
Subject RE: [Xalan2] Namespaces Problem
Date Thu, 19 Oct 2000 14:05:21 GMT
> How's performance?  
[snip]
> I'm especially interested to hear if you cocoon guys can notice the
> incremental performance now.  I fixed the last bug in that 
> respect, and you
> should see an interesting change in response time.

Here is my report (JDK1.2.2 win32 + Hotspot 2 , average on 1000loops) : 
-----------------------------------------------------------------
                     | empty.xsp | simple.xsp | sitemap.map |
-----------------------------------------------------------------
 SAX/XalanJ2BeforeOp | 80 ms         | 350 ms     | 3000 ms     |
-----------------------------------------------------------------
 SAX/XalanJ2Latest   | 16 ms         | 110 ms     | 550 ms     |
-----------------------------------------------------------------

Show we do see improvement, definitely, it's a great move !!!

What is even great is the incremental performance : The more we make loops,
the faster the whole porcess is, which is exactly the strenght of the Java
server side. 
For the sitemap example it takes 20 loops (with a time of 1000ms) before the
time drops to 400ms, which is damn unbelievable when compared to the
BOMbased XSP engine/XalanJ1 which reported 12000 ms/loop !!!

> 
> The measurements I'm taking still show Xalan2 a bit slower 
> than XalanJ1.

I'm not sure I agree with you on this point anymore :-)

> However, I'm measuring the Xerces serializers against the old Xalan
> serializers, which I think were quite a bit faster.  Assaf's 
> fancy layers
> may be art, but serialization is very time critical code.  A huge
> percentage of the overall profiles, like 40%, are being spent in the
> serialization layer.

If this is true, then we -at cocoon2- should be careful when using the
serailize package. In the SAX based XSP engine, we make use of it, so we
might double check the real impact.

> 
> Anyway, I suspect *basic* transforms at the XalanJ2 level are 
> now faster
> than XalanJ1.  

Indeed this is what is happening here.

> But this stuff is still highly case-by-case 
> dependent.  Many
> selection patterns will probably be a bit faster in XalanJ1, 
> like "//foo",
> but this will improve quickly over time.  I suspect we're 
> well on our way
> to becoming as fast or faster than other Java processor competitors.
> 
> I think I'm going to give up on the optimization madness for 
> now.  There's
> still a lot to be done, but it's time that I clear my head on 
> this aspect
> for a few days.  I'll do some more work on optimized itterators, etc.,
> after I get back from ApacheCon.

Thanks for your great job, Scoot. We will definitely appreciate your
reactivity.

Sebastien

Mime
View raw message