XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
Jamil TaylorSubject: Why Is The Saxon Processor So Slow?
Author: Jamil Taylor
Date: 29 Sep 2007 06:57 AM
This is something that I've noticed for quite awhile now-- Saxon 8.9.0.3 is absolutely the slowest XSLT processor out of all choices in Stylus Studio. It takes significantly longer to complete a transformation than all the others.

For an XSLT 1.0 transformation, it took 1.6 seconds to complete.

For comparison, here are results for some of the others:

Built-in: 16ms
Java Built-in: 391ms
.NET Transform: 63ms
.NET Compiled Transform: 141ms

Postnext
Minollo I.Subject: Why Is The Saxon Processor So Slow?
Author: Minollo I.
Date: 29 Sep 2007 08:39 AM
That's because Saxon is hooked in Stylus Studio to provide debugging and backmapping information; by no means is Saxon slow; what you are experiencing is a side effect of its tighter integration in the Stylus Studio debugging framework.

We have improved things significantly in recent maintenance packages, and even more in the coming version this fall; what Stylus Studio version/build (Help > About) are you running?

Postnext
Jamil TaylorSubject: Why Is The Saxon Processor So Slow?
Author: Jamil Taylor
Date: 29 Sep 2007 08:49 AM
My current version installed is 2007 R2 Enterprise 894m.

Note that I have observed this same behavior with every R2 2007 Enterprise release I have ever had installed. .NET XslTransform and built-in both support debugging, correct? They are significantly faster in execution though. Hmm.

Postnext
Alberto MassariSubject: Why Is The Saxon Processor So Slow?
Author: Alberto Massari
Date: 01 Oct 2007 10:42 AM
Hi Jamil,
could you share your XSLT with us? Send it to stylus-field-report@progress.com and we'll check if it follows code paths that are not yet optimized.

Thanks,
Alberto

Postnext
Jamil TaylorSubject: Why Is The Saxon Processor So Slow?
Author: Jamil Taylor
Date: 01 Oct 2007 06:40 PM
I just emailed a ZIP file containing my Stylus Studio project files to the email address specified. It is a small project, but it demonstrates what I have described.

Thanks.

Postnext
Alberto MassariSubject: Why Is The Saxon Processor So Slow?
Author: Alberto Massari
Date: 03 Oct 2007 10:39 AM
Hi Jamil,
thank you for sharing your project with us.
I tried running the ValidatorToHtml.xsl file on my computer, and these are the results:

Processor Min Max
Builtin 20 ms 60 ms
Saxon 219 ms 431 ms
Java builtin 181 ms 371 ms
.NET 101 ms 180 ms

My numbers seems comparable to yours, but the Saxon ones; I have tried with both JVM 1.5 and 1.6. Which one are you using?

Alberto

Postnext
Jamil TaylorSubject: Why Is The Saxon Processor So Slow?
Author: Jamil Taylor
Date: 03 Oct 2007 05:48 PM
I am running 1.6 on a decently classed machine (CPU power, memory, etc).

Saxon is a little faster if I set the execution mode to basic. The transformation executes in 1.2 seconds then (I just ran it). This is the first time executing it after starting Stylus Studio. All of my timings have been the first execution for each processor.

Postnext
Alberto MassariSubject: Why Is The Saxon Processor So Slow?
Author: Alberto Massari
Date: 04 Oct 2007 09:36 AM
Hi Jamil,
you should discard the timing of the first execution after Stylus starts; there is a certain amount of one-time operations (initializing the JVM, loading the Saxon JARs) that is not part of the XSLT processing. You should get lower numbers for any other subsequent execution.

Alberto

Postnext
Jamil TaylorSubject: Why Is The Saxon Processor So Slow?
Author: Jamil Taylor
Date: 04 Oct 2007 10:07 AM
That explains it.

Thanks.

Postnext
Jamil TaylorSubject: Why Is The Saxon Processor So Slow?
Author: Jamil Taylor
Date: 05 Oct 2007 10:21 AM
>you should discard the timing
>of the first execution after
>Stylus starts; there is a
>certain amount of one-time
>operations (initializing the
>JVM, loading the Saxon JARs)
>that is not part of the XSLT
>processing. You should get
>lower numbers for any other
>subsequent execution.

Thinking about this a little more, would it make sense to do all this setup in a separate thread during startup? It's around one second of initialization that could occur during startup, correct? This way, I receive the correct timings during transformation the first time I execute.

Should I post this under feature request?

Postnext
Alberto MassariSubject: Why Is The Saxon Processor So Slow?
Author: Alberto Massari
Date: 05 Oct 2007 12:03 PM
Hi Jamil,
unfortunately it's not possible to move this initialization phase to the startup of Stylus, as the JVM could crash if the user specifies the wrong options (and with the JVM crashing at startup the user could not access the option page to fix the parameters). Also, we would get the complaints of those users using Stylus to run only .NET processors....

Could you elaborate why the first execution timing worries you so much?

Thanks,
Alberto

Postnext
Jamil TaylorSubject: Why Is The Saxon Processor So Slow?
Author: Jamil Taylor
Date: 05 Oct 2007 12:29 PM
Until this thread, I was not aware that I should ignore the first execution of a Saxon-based XSLT transformation. If I throw away the results of the first execution, then Saxon is no longer the slowest processor.

However, if this initialization is required (for whatever reasons), then I cannot throw away the results of the first execution. Saxon is the slowest processor for XSLT transformations. If the reasons for it being the slowest is the loading of Saxon jars, I do not understand why the loading of jars cannot be done during startup. Loading the jars could crash the JVM? Perhaps I should just avoid Saxon...

I am a .NET developer, and I would not complain about the loading of jars in a completely different thread. Of course, I cannot speak on behalf of all .NET developers, but I would not understand the reason behind those who would complain about it.

If Saxon is the fastest/best/etc, I am not seeing proof of that in this implementation of it. It's really not that big of a deal to me, but it is good for analysis.

Posttop
Alberto MassariSubject: Why Is The Saxon Processor So Slow?
Author: Alberto Massari
Date: 05 Oct 2007 01:23 PM
Hi Jamil,
I think we are talking about different things here; if you want to discover which processor is the fastest, you should know that every benchmark will always discard the first iteration, the fastest and the slowest and then average a certain amount of executions.
As for the JVM crashing, I didn't state that loading Saxon jars crashes the JVM; I said that loading the JVM with certain user-specified options (like "allocate 4Gb of memory") will cause a "panic error" in the JVM that kills Stylus.

Hope this helps,
Alberto

 
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

Site Map | Privacy Policy | Terms of Use | Trademarks
Stylus Scoop XML Newsletter:
W3C Member
Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.