Débutant en SPIP il y a 2 mois, j’ai été gêné par l’absence de messages d’erreur en cas de paramètres de boucle ineptes. Du coup, j’ai regardé le code du fichier inc-calcul-squel.php3, et l’ai modifié en appliquant des techniques standards de compilation pour clarifier le code produit, savoir :

-  éliminer l’affectation d’une variable inutilisée ou réaffectée dans la suite du code ;

-  éliminer l’affectation d’une variable utilisée une seule fois dans la suite du code,
en remplaçant cette unique occurrence par la partie droite de l’affectation ;

-  remplacer toutes les occurrences d’une variable par sa valeur lorsque celle-ci est connue à la compilation ;

-  remplacer « if condition alors sinon » par l’alternant approprié lorsque la condition est connue à la compilation (constante ou objet non vide typiquement)

-  éliminer « while condition  » (cas se produisant avec TOTAL_BOUCLE, qui est en fait équivalent à num_rows ce que SPIP ne permet pas de dire autrement qu’en
parcourant toute la table, ce qui n’est ainsi plus le cas).

Ces méthodes ont apporté un gain de 50% sur les squelettes standards :

Les bugs repérés :

-  en cas de hiérarchie, les Rows n’étaient pas transmises aux boucles internes (par suite d’une confusion entre la variable $boucles du compilo et $pile_boucle du squelette produit) et les doublons étaient mal calculés (même cause, avec $doublon et $instance->doublon) ;

-  dans la fonction principale du squelette, on pouvait référencer $id_instance qui n’y est pas définie (bug visible dans le squelette forum) ;

-  le + important : le séparateur (paramètre comme {", "}) était rajouté à chaque tour de boucle, et non à chaque fois qu’un résultat nouveau est produit, ce qui n’est pas la même chose en cas de boucles imbriquées (voir exemple utile en pièce jointe : calcul de tous les mots-clés de toutes les rubriques).

En outre, un paramètre fautif est dénoncé (ceux de BIOSPIP oublient les guillemets, d’où absence de séparateur, sans explication ; j’ai prévenu l’auteur qui a corrigé).

Les optimisations réalisées devraient diminuer la taille des processus (moins d’allocation de mémoire) et autoriser les squelettes à rester plus longtemps dans le cache disque du serveur. Sur la durée d’exécution du processus lui-même une amélioration n’est perceptible que sur des exemples où la base de donnée est
réduite, car les réponses de MySQL sont le plus gourmand en temps.

Une suite à mon travail serait précisément de calculer les champs effectivement utilisés dans un squelette pour minimiser ces réponses (c’est d’ailleurs ce qui est
fait depuis longtemps pour la table ARTICLE). Je veux bien me lancer là-dedans,
mais il faudrait d’abord intégrer ce que j’ai fait au CVS. J’étais parti de la version
1.6 officielle (fichier inc-calcul-squel du 10 Mai), je veux bien prendre le temps de synchroniser avec la dernière version sur CVS (le diff avec la 1.6 est encore assez petit) si vous souhaitez adopter mon travail. A signaler que j’ai éclaté ce fichier en
5 (parsing/production/debug/écriture/donnees) ce qui réduira d’ailleurs les conflits
d’accès sous CVS par la suite.

La première pièce jointe contient les 5+1 fichiers PHP.
La deuxième est une modif du squelette sommaire, comportant le calcul de tous les mot-clés du site.

Tout commentaire est évidemment le bienvenu.