Even compare C processor like libxslt?
Lionel Villard
IBM T.J Watson
| "Igor Hersht" <[EMAIL PROTECTED]>
07/23/2003 12:47 PM
|
To: [EMAIL PROTECTED] cc: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: RE: Benchmarks (XalanC + XalanJ) |
I am running a lot of benchmarks (including XSLTMark and XSLTBench)
regularly.
We work hard to improve XalanC +and XalanJ performance.
According to my measurements the latest XSLTC is the fastest Java
processor.
I didn't do any measurements on XalanC, but I am working on it.
It is our immediate goal to improve XalanC performance.
I think we have good potential here.
There is another important point about XML and XSLT benchmarking.
Benchmarking results depend critically on a particular benchmark, execution
scenario, and measurements metrology. We should be a little bit skeptical
about results reported by any particular company. What we really need is a
"Industry standard benchmarks" - recognized standard for performance
evolution. This is how it works in "classical" environments like C++ and
Java compilers.
Igor Hersht
XSLT Development
IBM Canada Ltd., 8200 Warden Avenue, Markham, Ontario L6G 1C7
Office D2-260, Phone (905)413-3240 ; FAX (905)413-4839
"Gounder, Palanisamy"
<[EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'"
ercomm.com> <[EMAIL PROTECTED]>
cc:
07/01/2003 06:37 PM Subject: RE: Benchmarks (XalanC + XalanJ)
Please respond to
xalan-dev
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
