[Résolu] Benchmark pour transformations XSLT

Salut

Je recherche des infos concernant les recommandations d'écriture/codage des feuilles XSL afin d'optimiser des transformations. Je n'ai rien trouvé de probant sur le sujet (et ce quel que soit le moteur utilisé). En fait, la seule information que j'ai pu trouvée était très vague et indiquait que selon le proc utilisé, les résultats étaient variables... ce qui ne m'avance pas énormément.

Existe-t-il une alternative au fait de devoir se taper l'optimisation à coup de xsl:template match pour chaque pattern? Ou existe t-il un moyen de tester toutes les parties de la feuille XSL en une seule passe?
Dans ce dernier cas, j'ai trouvé catchXSL. Quelqu'un l'aurait-il déjà utilisé http://www.xslprofiler.org/overview.html (ceci dit il ne semble fonctionner que pour Xalan et Saxon, ce qui n'est pas mon cas je suis sous DomXml/PHP5)? Si oui, est-ce vraiment efficace comme outil pour permettre l'optimisation d'une feuille XSL ?

merci par avance,
microtom

Ps : j'ai posté ce message sur phpscripts, mais n'ayant pas eu de réponse probante je poste le même ici...
Modifié le 29 Jan 2005 - 22:44

Ma réponse à ta question, fort intéressante au demeurant, ne sera que très partielle, je m'en excuse.

1/ DOMXML
Attention DOMXML qui faisait partie de PHP4 a été retirée de PHP5 (et intégré dans les extensions PECL). L'API DOMXML a été remplacée dans PHP5 par 2 API : DOM et XSL. DOM et XSL sont proches de DOMXML et restent basées sur les librairies libxml2 et libxslt. Donc je te conseille plutôt d'utiliser les API DOM et XSL. La bonne nouvelle pour toi est que libxml2 et libxslt constituent de très loin le processeur xslt le plus performant (bien plus que Xalan, Saxon, Sablotron).

2/catchXSL
Fonctionne effectivement en environnement Java donc pas avec libxml2 et libxslt (écrites en C) et donc pas avec les API PHP dont nous avons parlées.

3/recommandations d'écriture/codage des feuilles XSL
Je ne connais pas de documentation sur le sujet, mais les spécialistes savent comment optimiser l'écriture de transforamtion XSLT. Il s'agit d'ailleurs de bon sens :
- minimiser le nb de noeuds auxquels on accède
- minimiser les boucles
- préférer un parcours séquentiel à un accès aléatoire sur les noeuds...
toutes choses qui ont un sens lorsqu'on écrit du XSLT.

Je pourrais recommander la pratique opérationnelle suivante :
- optimiser la feuille XSLT en utilisant Saxon et catchXSL (simples à installer si l'on dispose d'un environnement java). Si les progrès sont significatifs ils se verront aussi sous libxml2 et libxslt.
- valider l'amélioration sous PHP en utilisant l'affichage de timestamp avant et après transformation.

Salut

Merci pour toutes ces informations Xavier.

En prime, ton point 1/ est un rappel pas du tout inutile et qui m'apprendra à mieux formuler mes questions (honte à moi)

>minimiser le nb de noeuds auxquels on accède
Tu veux dire que dans une XSL il ne faut pas qu'il y ait trop de règles ou que pour chaque pattern il faut aller droit au but ?

>préférer un parcours séquentiel à un accès aléatoire sur les noeuds
Là je n'ai pas trop compris! Aurais tu un exemple sous la main?


En tout cas encore une fois, merci

microtom

a écrit :
>minimiser le nb de noeuds auxquels on accède
Tu veux dire que dans une XSL il ne faut pas qu'il y ait trop de règles ou que pour chaque pattern il faut aller droit au but ?

Oui droit au but. Il vaut mieux définir pour chaque template une liste de noeuds courante la plus étroite possible correspondant au besoin, plutôt que d'être lâche sur cette liste puis de devoir faire des tests ensuite.

a écrit :
>préférer un parcours séquentiel à un accès aléatoire sur les noeuds
Là je n'ai pas trop compris! Aurais tu un exemple sous la main?

On peut être plus ou moins directif pour le parcours de l'arbre source. Le moins directif est le plus rapide. A la limite si l'on ne dit rien, le processeur parcourt l'arbre source dans l'ordre naturel (ordre "séquentiel" et donc rapide) à partir des règles modèles par défaut.
A l'inverse on peut demander le noeud 12, puis le noeud 150, et le noeud 45 ... c'est ce qu'on appelle l'accès direct pour l'utilisateur (le programmeur) mais vu du processeur c'est un accès aléatoire. Donc pour chercher un noeud précis il repasse sur tout (ou une bonne partie) le document source.

Et en résumer, relativement à un besoin donné :
- il faut éviter les templates trop spécifiques qui vont accumuler les accès "aléatoires"
- il faut éviter les templates trop génériques qui pourraient conduire à parcourir des zones inutiles du document.

Ok là c'est plus clair.

Merci beaucoup pour tous ces conseils