From mboxrd@z Thu Jan  1 00:00:00 1970
From: Anthony Green <green@redhat.com>
To: rhug-rhats@sources.redhat.com
Cc: java@gcc.gnu.org
Subject: Xalan: gcj -vs- jre 1.3 
Date: Sat, 15 Sep 2001 13:41:00 -0000
Message-id: <200109152041.NAA22016@fencer.cygnus.com>
X-SW-Source: 2001-09/msg00029.html

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