[mod_python] XSLT versus 'traditional' templating (was: mod_python Live examples)

Byron Ellacott <bje at apnic.net> writes:

> > And note that XSLT doesn't have to be slow; there's quite a lot of
> > research going into improving speed. The pipelining approach has
> > already been taken:
> >   http://xml.apache.org/xalan-j/xsltc_usage.html
> 
> Sorry, but I'm not sure what you mean by pipelining.  Since an XSLT 
> document can, at any point, examine any part of the source document, you 
> /must/ have the entire source document available to perform a transform. 
>   Consider how you would implement <xsl:value-of 
> select="//foo/bar[@baz='quux']"> without a full document, for instance. 
>   In essense, XSLT is a document transformation tool, whereas 
> traditional HTML templating mechanisms, including PSP, are stream 
> templating tools.
> 
> On the other hand, it's perfectly valid to compile the XSLT document to 
> some other, more convenient form, thus saving on the parsing, and it's 
> also valid to cache DOM trees instead of XML strings.  But these don't 
> change the basic fact that an XSLT transformation is still more complex 
> than your ordinary run-of-the-mill template translations.

Yes, that's right. That's what xsltc does. The templates are compiled
into code that operates on a stream. It's clever and fast, but it's
also complicated.


> > In a RESTfull application you could also just add another server.

> And I am talking not about scalability performance, but about
> per-request response time.  If the system starts too slow to use for
> one user making one request at a time, scaling well will simply mean
> it can be too slow for lots of users at once.

What I was trying to say was that the biggest factor in XSLT
computation is memory size. If you can fit all the requests' DOM's
into memory then you will reduce the speed problem. I've recently been
working on a Java webapp with a similar architecture to the one you've
outlined, it is awfully slow when it isn't run on very large memory
servers but on big memory machines it's very quick.

But you're right. Stream based templating is always going to be
quicker.


> > Python doesn't have 'standard' XSLT support yet... but when it
> > does it will be possible to pass DOMs around instead of XML
> > character streams. That will speed things up considerably.

> Sure, or you just say that you expect DOMs to be of the type you can
> handle.  You're defining an API, you can also define the types of
> the arguments and return values.

That's true. But I was getting at the performance issue. Currently
it's likely that passing your 'DOM' to an XSLT engine will require
serializtion of your DOM and then the XSLT engine to parse the
serialized form. 

When there is standard Python XSLT support we will presumably be able
to pass a DOM directly to an XSLT engine which will operate on it
directly. This is how one achieves reasonable XSLT performance with
Java for example.


> These aren't reasons to avoid the technologies, they are tradeoffs.
> Your application will almost certainly feel slower, but it's likely
> to have much better decoupling and maintainability, if you use XSLT
> to transform XML data to markup.

I do agree with you. But I think your assesment of XSLT as slow is
(only) slightly misleading. Partly it's slow in Python because of a
lack of standard support (although this can be fixed by using things
like libxml2 for your xml and xslt).


Nic