XSLTC is the best among XALAN-J and SAXON but I am not able to use it because of the bug #20470 problem. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20470
I tested my XSL with SAXON 6.5.1 and it gives much better performance than XALAN-J. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 10:48 AM To: [EMAIL PROTECTED] Subject: Re: Benchmarks (XalanC + XalanJ) Hi HolgeR, > Hi David, > > [EMAIL PROTECTED] schrieb: > > 1. Xalan-C might not do well on some of the tests performed. > The point is, Xalan-C 1.3 is slower than saxon in 14 of 15 (nearly all) tests. Hmmm, I guess I need to take a look at this. > > 2. Xalan-C has not seen much work lately, and there are lots of > > optimizations in Xalan-J which could be applied which would help improve > > performance. > In the study Xalan-J 2.3.1 is slower than saxon in all the tests and slower than > Xalan-C 1.3 in 13 of 15 tests. Those are both old versions of Xalan, so that might explain it. There are lots of new optimizations that have been introduced into Xalan-J since that version. > > 3. They may have chosen a bad platform for Xalan-C. Xalan-C is > > sensitive to the quality of code generated by the compiler for a > > particular platform, and some platforms don't do well. For example,GCC > > on Linux does not always do a good job optimizing. > > 4. Older versions of Xalan-C may not produce the same results that newer > > versions do. If an older version is used for the benchmark, the results > > may not be as good as they would be if a newer version were used. > They have tested Xalan-C 1.3, the benchmark is available ( http://www.sarvega.com). I > run the saxon/xalanc tests on my Win32 (W2KSP3) machine (PIII 800MHz) with Xalan-C > 1.5. I found Xalan-C 1.5 is *faster than saxon* in 10 of 15 tests. This may be the > result of a) the win32 platform, b) the newer version of Xalan-C or c) the slower > processor. Maybe I run some other tests to answer this question. Probably a combination of a and b. > > It's very curious, because there are such conflicting reports. Dmitre > > Novatchev stated in was unfortunate that he couldn't get timing information > > out of Xalan-C, because he felt it was one of the fastest processors. > > Others have also stated they've switched from Xalan-J to Xalan-C for speed > > reasons. > Hey, don't question yourself or Xalan-C. I like Xalan-C. I had written an article for > a german XML magazin (Holger Floerke, "XML-Verarbeitung in C++", Der Entwickler (XML > Magazin), 1/2002, Software&Support Verlag - no English version available). The > conclusion is: If you have to transform *large* documents (espacially for converting > publikation data), you *have to* use Xalan-C because of the small memory usage. > Xalan-C is good, small, and fast. Don't worry -- I'm not questioning myself or whether Xalan-C has any value, it's simply that the Xalan-C team has not had the resources in the past to do many things I would like to do. There is also value in being a cross-platform C++ processor, which MSXSL will never be. It's good to know you confirm what I've seen -- that Xalan-C's memory footprint is much smaller than the Java processors. Is there, by any chance, an on-line version of your article? I would love to read it, even in German. > Maybe such benchmarks can help us to concentrate on real bottlenecks. In this case > there is one test, where Xalan-C achieves only 17% of the performance of saxon. Absolutely. I will look at this as soon as I can. Dave
