Latest: buggy behaviour of parent:: in PHP 5.3.3

Content with Style

Web Technique

DOs and DONTs in XSLT

by Pascal Opitz on June 4 2007, 11:43

A nice little roundup of how to efficiently use XSLT can be found here

I came accross this link when reading about Push vs Pull XSL , something thatw ill change my approach on XSL quite a lot. Reading up on modes, push vs pull and so on basically gave me one of these moments that you had when you realized that tables and the way you were using them where not really appropriate in HTML.

Quite a drastic quote, but true if I consider how I did my XSL code until now, I can only say he’s right:

Whether your favorite conceptual module is pipes and filters, tuple spaces, or just good ol’ lambdas, a fundamental understanding of push techniques is essential if you want to ever do any serious development in XSLT. New arrivals to this field take short-cuts only to get lost later. From a purely practical point of view, I think it’s important to teach apply-templates, modes and friends well before for-each, and bitchin’ value-of tricks.


  • I did some testing before and after cleaning up my stylesheets. I removed all instances of ”//” and most “for-each” cases and compared performance. The results of the comparison of transform times showed no change(or too small to measure). It was disappointing to do all that work and not see any improvement.

    Granted, extensibility increased, but it wasn’t a big deal given the system we were using.

    by jethro on June 20 2007, 19:37 - #

  • Hi jethro,

    increases in speed come mainly down to the size of the XML you have to parse. A // on 3 nodes is nearly as fast as navigating to /root/node[position() = 1] but the same query on 10000 nodes is not going to be nearly as fast.

    I can understand why you feel a bit disappointed, for sure, but if you haven’t been experiencing any speed problems before, why did U do a tidy up in the first place? If the performance issues that you had were somewhere else in the application, then for the next time you might consider to benchmark single steps in order to single out the bottleneck.

    Tools like the PEAR benchmark package really help.

    In my previous projects we did exactly that, and we successfully pinned down what it was: a // xpath query on a 5 meg XML document.

    by Pascal Opitz on June 21 2007, 18:19 - #

Leave your comment

Comments are moderated.
Tags allowed: a, strong, em, code, ul, ol, li, q, blockquote, br, p