It sounds to me as if you want a processor that's good at handling large documents; that's an entirely separate question from whether it's compiled or interpreted: in particular it's more to do with memory management than with execution speed.

I have to say my experience is that XSLT processors benefit immensely from running on a platform that gives you garbage collection for free. In principle, you can write custom memory management that's better than a general-purpose garbage collector, but it's very hard work.

Michael Kay
http://www.saxonica.com/
Author, XSLT Programmer's Reference and XPath 2.0 Programmer's Reference

Do you know of a specific Sun compiler example? Or have any preference for a C/C++ based processor to handle large volumes of low level transformations? (avg file size is about half a meg)

Most information I've sifted through, including benchmark data, seems to be very outdated, so we may be using libxslt because it was the fastest 7 years ago, but other processors may have marched on. On top of that, most processors are designed for Java environments, and we strictly need a C/C++ one.