Ever wanted to know where your XSLT transformations spend most of their time? Look no further than this patch to the PHP XSL extension. It uses the built in profiler of libxslt to get the information which template was called how many times and how much time was spent in them. It may help in improving the speed of your XSLT transformations, like a PHP debugger can help in profiling your PHP scripts.

The profiling information is written into a file, which you can enable the following way:

$proc = new xsltprocessor(); 
$proc->importStylesheet($xsld); 
$proc->setProfiling("/tmp/xslt-profiling.txt"); 
print $proc->transformToXml($dom);

And then read the file with any text-editor. I will commit the patch to the PHP CVS repository, but as PHP is now in a release phase, this has to wait until later. If I'm allowed at all to put this new feature into the PHP_5_2 branch, but HEAD shouldn't be a problem.

Our experience also showed, that the import of the stylesheets (->importStylesheet() above) can also be a performancekiller, as much as the actual transformation, especially if you have a lot of xsl:import or xsl:include in your code. You can profile the time taken for the whole importStylesheet call with any php profiler (or just with microtime()), but if you want to know, how much each stylesheet took, there's no easy way. Therefore I wrote a little quick&dirty patch to libxslt itself, which writes some profiling information collected during the import phase directly into the hardcoded /tmp/xsltbench.txt. I just wrote that patch for me, so don't expect it to be really self-explanatory (or tested), but it may nevertheless help some of you in finding bottlenecks.

Maarten Manders @ 29.04.2007 22:32 CET
Good news, thanks Chregu! Seems to coincide with my assumption that xsl:import's are slow, as we talked about.

Chris D @ 29.04.2007 23:37 CET
Glad to see you post about PHP again.
I very much enjoyed your posts about PHP in the past (and the work you did on PHP) and was wondering if you had moved on from PHP.

chregu @ 30.04.2007 06:33 CET
Maarten: I didn't actually say, they are slow per se, nor did I any real benchmarks or comparisons with them, that's still awaiting. My basic conclusion until now was, that the import phase can be slow, because one imports too much :)

But I'll see, if I can bring some more light on this issue in the feature.

Chris: Nono, I/we didn't move away from PHP, just too many other things on the map :)

chregu @ 30.04.2007 09:41 CET
Maarten, here's a little quick&dirty benchmark. The import/include stuff included 10 xsl stylesheet, in "all" I put all the templates in one big (approx. 140kb) xslt. The script basically did this:

$xslno = domdocument::load("xslimport/master.xsl");
$xsl0 = new xsltprocessor();
$xsl0->importStylesheet($xslno);
$xsl0->transformToDoc($xml);

and these are the times for that case:

xslt import 0.281
xslt include 0.271
xslt all 0.311

So, the "putting everything in one stylesheet" was slower than the other 2 methods for this case (measured on my macbook pro with libxslt 1.1.20)

Maarten Manders @ 30.04.2007 13:35 CET
Chregu: Interesting, wouldn't have expected that. I once did the same benchmark with fewer templates. Back then, I thought the setup was flawed, as I didn't trust the numbers. Seems smelly to me that the big XSLT is considerably slower than the imported ones...

Haven't there been any effords to cache imported stylesheets, as the opcode cache does for PHP scripts? It seems like a big waste of resources to me.