* Xalan: gcj -vs- jre 1.3
@ 2001-09-15 13:41 Anthony Green
2001-09-15 14:13 ` Cedric Berger
0 siblings, 1 reply; 3+ messages in thread
From: Anthony Green @ 2001-09-15 13:41 UTC (permalink / raw)
To: rhug-rhats; +Cc: java
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Xalan: gcj -vs- jre 1.3
2001-09-15 13:41 Xalan: gcj -vs- jre 1.3 Anthony Green
@ 2001-09-15 14:13 ` Cedric Berger
2001-09-15 15:22 ` Anthony Green
0 siblings, 1 reply; 3+ messages in thread
From: Cedric Berger @ 2001-09-15 14:13 UTC (permalink / raw)
To: green; +Cc: rhug-rhats, java
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Xalan: gcj -vs- jre 1.3
2001-09-15 14:13 ` Cedric Berger
@ 2001-09-15 15:22 ` Anthony Green
0 siblings, 0 replies; 3+ messages in thread
From: Anthony Green @ 2001-09-15 15:22 UTC (permalink / raw)
To: Cedric Berger; +Cc: rhug-rhats, java
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-09-15 15:22 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-09-15 13:41 Xalan: gcj -vs- jre 1.3 Anthony Green
2001-09-15 14:13 ` Cedric Berger
2001-09-15 15:22 ` Anthony Green
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).