After Rob’s idea from yesterday about using XMLReader within XSLT I was wondering, how much of a slowdown calling PHP functions from XSLT is.
I wrote 4 different XSLT templates, which do a simple substring. One with the xslt function “substring”, one with just calling the native PHP function “substr” and one with calling a user-defined function (which is also just calling “substr”). I called this 100 times (with one of those great recursive self-calling xslt-templates) and did call the “transformToXML” function a 100 times for each stylesheet. This means, we called the function 10’000 times for each benchmark run.
For comparison, I also did an XSLT with no function call at all, just the recursive template and a simple xsl:value-of.
|mode||Total time||Time per function call||Difference to nocall|
|nocall||57 ms||0.006 ms||-|
|xslt only||98 ms||0.010 ms||0.004 ms|
|php native||146 ms||0.015 ms||0.009 ms|
|php userland||194 ms||0.019 ms||0.014 ms|
Calling PHP functions from XSLT is significantly slower, if you look at these figures, but IMHO opinion the difference is somehow negligible. You’re usually not calling thousands of PHP functions per run, and even if you do, your XSLT template may be a little bit more complex than the example and the difference to the whole should not be really recognizable. And you gain a lot of functionality, which is just not possible with XSLT only otherwise or would need some really awkward workarounds (which almost certainly will slow down the transformation also :) )
And here’s the PHP script itself.
Possible good comparison.
Dokuwiki’s parser turns a raw wiki page into a flat array, which corresponds to callback functions – the “Renderer Instructions” described here: http://wiki.splitbrain.org/wiki:parser#overview
These are then called against methods in this class: http://dev.splitbrain.org/view/darcs/dokuwiki/inc/parser/xhtml.php
Would be relatively easy to convert the array to XML as input, then it’s a matter of re-implementing that Doku_Renderer_xhtml class as XSLT. Because the array is flat, would mean the stylesheet rules should be very simple.
Anyway – one to add to that “coding distractions” TODO list.
Current state: pondering. A contest is a good idea – been too busy recently for fooling around but may give it a shot next free moment.
Yeah, that’s one of my longer term projects:
Do a “real” templating task in XSLT and one in PHP (or in a PHP template language) and see what is faster :)
Besides not finding the time for doing it, I have yet to find a simple enough real world scenario for something like.
But why not opening that up to a little conquest: Who can write the fastest “application”, which does a certain task in his favourite templating-or-whatever language. The “application” would need some logic, otherwise the results are of not much use, but shouldn’t be too large so that it can be done in a decent amount of time.
Interesting. How do the xslt substring version compare with something “pure PHP” (i.e. no XSLT – just a loop with a call to substr)?
Last time we talked about that, go me wondering – for example can imagine libxml2 can probably parse and execute XSLT faster than a PHP script gets executed, at least without OPCODE cache.
Perhaps if you bring into play all the things people normally do when it comes to templates and “view logic” in PHP, XSLT (without calls to PHP functions) works out faster overall?