p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   XSLT (http://p2p.wrox.com/forumdisplay.php?f=86)
-   -   XSLT Compiler for C/C++? (http://p2p.wrox.com/showthread.php?t=68769)

unclejemima June 12th, 2008 09:04 AM

XSLT Compiler for C/C++?
Does anyone know of an existing XSLT Compiler for C or C++, such that it takes as input an XSL stylesheet and outputs some form of executable code, binary, compiled C code, assembly, shared library, etc. which can then be directly executed to convert XML files?

is a proof-of-concept implementation that has been dead since the year 2000.
I realize there are java, HTML compilers out there that perform the task, but I am under a C/C++ constraint with a speed/efficiency priority, worst case would be using an interpreter or doing inter process communication with a fast java compiler like Gregor/XSLT.

Anyone got any tips or ideas?

samjudson June 12th, 2008 09:19 AM

Xalan C++ supports compiled stylesheets - but I don't know if there are capabilities for storing that compiled object (in C# you'd just serialize the object, but can you do that in C++?)

/- Sam Judson : Wrox Technical Editor -/

unclejemima June 12th, 2008 09:31 AM

The program needs to handle multiple dynamic XSL stylesheets and for each stylesheet, multiple XML inputs. The problem is that most C/C++ xSlt handlers are interpreters, which XALAN C++ also is. The speed of a Java XSL compiler versus an interpreter isn't even a contest. Right now, we are using libxslt which is also an interpreter/processor. (takes as input, xsl sheet and xml file, runs interpreter through the xsl sheet and applies to xml file). something that could precompile the xsl sheet and then run all xml files through uninterpreted code would obviously be infinitely faster. unfortunately, no such thing seems to have been developed for C/C++, even though there are multiple Java based platforms.

mhkay June 12th, 2008 09:55 AM

>The speed of a Java XSL compiler versus an interpreter isn't even a contest.

What makes you think that? It simply isn't true.

I think you'll find that the benefits of compiling are less dramatic than you think. That's partly because most of the time is likely to be spent in the run-time library, which will be identical in both cases. Saxon-SA will output Java code which can be compiled, and the performance benefit is typically about 25% (though within a range from 0% to +50%). That's useful to have, but far smaller than the variations between different XSLT processors.

Having said that, it might be worth looking at the Intel XSLT processor. I don't know if it meets your definition of a compiler - to be honest, the boundaries between compilers and interpreters are getting very fuzzy these days - but it might meet your needs. Unfortunately it's only XSLT 1.0 at the moment.

Michael Kay
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference

unclejemima June 12th, 2008 10:10 AM

Hmm, was I mislead in thinking that compilers like Apache XSLTC, Gregor/XSLTC or even your Saxon commpiler are immensely faster than interpreters for high XML volumes? To be honest, it was more conceptual and word of mouth based logic than actual objective information. You should know better than I do if you worked on the Saxon platform. As for Saxon itself, is it highly compliant but not as fast as the Intel processor? Intel claims that their XSLT accelerator is 2x faster than XSLTC so this might be on the right track.

joefawcett June 12th, 2008 10:20 AM

As Michael said there's no real reason for saying this, it's a bit of an old wives' tale. The .NET JIT compiler is often faster than C++ code as it can highly optimise the code. For something like a device driver you'd probably stick to C++ but once you've loaded the .NET framework/Java VM performance for everyday code is not going to be worse.
You can compile stylesheets into assemblies for use by .NET but then you'd have to use managed C++.


Joe (Microsoft MVP - XML)

unclejemima June 12th, 2008 10:29 AM

I forgot to mention that currently we are implementing libxslt based on some benchmarking data we saw, which is C++ based. I'm also not sure from looking at the Intel Accelerator whether it is purely meant for Java environments or has a Java and C/C++ API In your opinions, would it be faster to use libxlst as is, is the intel processor faster, i was warned for business reasons to stay away from microsoft but would the .NET compiler actually be even better?

mhkay June 12th, 2008 10:49 AM

I don't have any figures, either my own or third parties', comparing the Saxon processor with Intel. I get the impression they have concentrated more on low-level optimizations (close to the hardware and memory management) whereas I have concentrated more on algorithmic optimizations. The expected outcome from that would be that the Intel processor performs better on simple transformations and Saxon performs better on complex ones. But it would be nice to have evidence to see whether that theory is correct.

Most products these days, Saxon and Intel included, have a compile-time phase that generates some kind of executable representation, which is then executed at run-time by some kind of interpreter or virtual machine. Generating machine-level instructions, if it is done at all, is usually done at the last minute (just-in-time compilation). There really isn't a hard-and-fast distinction between compilers and interpreters any more.

Michael Kay
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference

joefawcett June 12th, 2008 10:50 AM

Not really sure, the compiled assembly only really speeds up the loading of the stylesheet anyway. If you are running the same transform against multiple XML files you only have a small initial hit, after that you're re-using the XslCompiledTransform instantiation.
Your case seems to be multiple stylesheets though so compiled stylesheets would probably help. Then again using XslCompiledTransform limits you to XSLT 1.0 whereas being able to use version 2.0, via Saxon, might speed things up anyway.


Joe (Microsoft MVP - XML)

unclejemima June 12th, 2008 11:13 AM

First, let me thank you both wholeheartedly for the timely response.

I've basically been given an ultimatum though. Despite the fact that there may only small performance gains, in handling millions of requests or with huge files, a small gain is a big deal. I'm told that we ran tests with huge files and the libxslt C-based interpreter took nearly half an hour whereas the apache xsltc compiler performed in nearly half a minute.

So I kind of need a final say recommendation, and considering I just saw a huge XSLT book with Michael Kay's picture on it, I'm sure you are more qualified than any us new users to answer. We either need:

1) A c/C++ xslt compiler that runs on sun or linux

or in the case that no such thing exists

2) The fastest c/c++ xslt interpreter that runs on sun or linux

**In either case, we only need XSLT 1.0 compliance, no need for extensions. Also, sorry, Joe, but I cannot use .NET JIT.

All times are GMT -4. The time now is 12:08 AM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.