Xalan: gcj -vs- jre 1.3

Xalan: gcj -vs- jre 1.3

[Anthony Green]

Now that Xalan appears to be working so well with gcj, I thought I'd
try measuring performance.  I've made some web pages for rhug (yet to
check in) which are constructed from XML source using XSL
transformations.  The xslt Process program has a -DIAG option to dump
out timing info for the transformation.  I've created an executable
for convenience sake called xsltp...

$ xsltp -IN rhug.rml -XSL rhug-info.xsl -OUT index.html -DIAG


========
Transform of rhug.rml via rhug-info.xsl took 219 ms


Here's the same thing with Sun's JRE 1.3 on IA-32 Red Hat Linux...

$ java org.apache.xalan.xslt.Process -IN rhug.rml -XSL rhug-info.xsl -OUT index.html -DIAG


========
Transform of rhug.rml via rhug-info.xsl took 3543 ms


Ok - we're roughly 16 times faster at this kind of batch processing.
Great.


Next I thought I'd try xsltc, which compiles XSL files to .class files
for performing xsl transformations..

$ time xsltc rhug-info.xsl
parseExpression exp = /rhug/info
parseExpression exp = document(@filename)/project
parseExpression exp = name
parseExpression exp = version
parseExpression exp = description

real   0m0.793s
user   0m0.720s
sys    0m0.050s

Ok.. then I tried JRE 1.3...

$ time java org.apache.xalan.xsltc.compiler.XSLTC rhug-info.xsl
#
# HotSpot Virtual Machine Error, Unexpected Signal 11
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
#
# Error ID: 4F533F4C494E55580E43505005BC
#
# Problematic Thread: prio=1 tid=0x804dda8 nid=0x67e runnable 
#
 
Ouch!  This reminds me of the early days of gcj development, but with
the gcj and JRE results reversed :-)

AG

Re: Xalan: gcj -vs- jre 1.3

[Cedric Berger]

Anthony Green wrote:

>Transform of rhug.rml via rhug-info.xsl took 219 ms
>
Do you understand, I hope, that this only measures the startup time
of the VM. This is where GCJ shines and where GCJ will be very useful.

Of course, nobody in is right mind will invoke the following command
to transform XSL documents in a production environment.

java org.apache.xalan.xslt.Process -IN rhug.rml -XSL rhug-info.xsl -OUT index.html -DIAG

What would be interresting is to "daemonize" the process, and see
how long it takes to transform a single document with a *running* VM.

And also, of course, since you used the latest GCJ, would you care
to do the same test with the latest JRE, which is 1.3.1_01 if I'm not
mistaken?

Cedric

Re: Xalan: gcj -vs- jre 1.3

[Anthony Green]

Cedric wrote:
> Do you understand, I hope, that this only measures the startup time
> of the VM.

Yes - of course. :-)   I thought I had put a caveat around it with "this kind
of batch processing".

> This is where GCJ shines and where GCJ will be very useful.

Yes.  My two other favorite benefits are (1) gcj may be available for targets
for which there are no JRE ports, and (2) tight-memory environments running
multiple java processes will benefit from having all of the library code in
shared libraries (and then there's the fact that it's Free software).

> Of course, nobody in is right mind will invoke the following command
> to transform XSL documents in a production environment.

Hmm.. why not?  This is almost exactly what "make htdocs" is going to do in
the rhug Makefile.  Do you just mean a production servlet environment?

> What would be interresting is to "daemonize" the process, and see
> how long it takes to transform a single document with a *running* VM.

Well, I just did another test with SAX2Count from Xerces.  It has a -w flag to
"warm up" the VM before timing.  I ran it on a large xml doc and they were
very close.  Gcj had a slight edge, but it was only about 15%.  Of course,
these benchmarks are somewhat meaningless because I'm not using the latest JRE
and the gcj library builds were not really tuned for performance.

> And also, of course, since you used the latest GCJ, would you care
> to do the same test with the latest JRE, which is 1.3.1_01 if I'm not
> mistaken?

I'm not all that motivated to do this.  I have easy access to the 1.3 version,
and the binary license for JRE 1.3.1 has some language that I don't understand
and find troublesome.

AG