C'est absolument vrai, il faut toujours éviter les "premature optimization" - cependant, la performance commence toujours par une architecture logicielle claire et pensée en premier lieu pour les performances. Quand on importe toutes les semaines de centaines de milliers de lignes de gros fichiers XML, la mécanique a sérieusement intérêt à avoir été pensée pour dès le départ.
Par exemple, l'auteur parle de Drupal, et je sais de quoi je parle j'en fais depuis presque 10 ans, et je suis certain que les gens ayant commencé le site ont utilisé les API de Drupal pour injecter le contenu. Cependant, ça devient très vite très compliqué (ça aurait été pareil avec une application Symfony ou Django basée sur un ORM) - où est la barrière que je peux franchir ou pas pour respecter les performances ? Est-ce que j'accepte de contourner les API du logiciel et potentiellement avoir des données obsolète dès leur import (évènements non lancés, listeners non reveillés) où est-ce que j'accepte que ce soit juste lent mais m'assure que tout le monde ai bien sa chance d'intervenir logiciellement au moment de l'injection des donnée ?
La réponse que j'aurais apporté à ce genre de problématique c'est que bien souvent l'outil de base est mal choisi, et dès ce moment, avant même qu'une seule ligne du logiciel existe, ce choix aurait pu permettre d'éviter d'avoir se poser ces questions là.
Puis, pour revenir au XML, utiliser du XPath, sérieusement ? Pour des très gros imports, si tu sais ce que tu fais et que tu connais le schéma, il faut mieux utiliser un lecteur séquentiel, comme l'API XMLReader, qui va juste être incroyablement plus rapide et ne pas consommer de mémoire, là où les implémentations basées sur la libxml2 (c'est à dire toutes en PHP, sauf l'API XML(Reader|Writer)) nécessitent de charger le fichier XML intégralement en mémoire, et en profitent pour passer une phase d'autocorrection du contenu (si si, ça le fait, et même plutôt bien).
Bref, les performances ça se prépare en amont:
éviter les optimisations prématurées permet d'éviter de créer des goulots au niveau des caches, et de rendre illisible une API qui aurait pu l'être,
penser le design logiciel dès le départ pour être taillé pour notre métier, quitte à rendre plus compliqué et plus lent les tâches annexes moins importantes,
bien choisir l'outil de départ,
éviter de tomber dans les pièges classiques/cas d'école.
[^] # Re: Optimisez la clarté de votre code !
Posté par Christie Poutrelle (site web personnel) . En réponse au journal Optimisez votre code !. Évalué à 8.
C'est absolument vrai, il faut toujours éviter les "premature optimization" - cependant, la performance commence toujours par une architecture logicielle claire et pensée en premier lieu pour les performances. Quand on importe toutes les semaines de centaines de milliers de lignes de gros fichiers XML, la mécanique a sérieusement intérêt à avoir été pensée pour dès le départ.
Par exemple, l'auteur parle de Drupal, et je sais de quoi je parle j'en fais depuis presque 10 ans, et je suis certain que les gens ayant commencé le site ont utilisé les API de Drupal pour injecter le contenu. Cependant, ça devient très vite très compliqué (ça aurait été pareil avec une application Symfony ou Django basée sur un ORM) - où est la barrière que je peux franchir ou pas pour respecter les performances ? Est-ce que j'accepte de contourner les API du logiciel et potentiellement avoir des données obsolète dès leur import (évènements non lancés, listeners non reveillés) où est-ce que j'accepte que ce soit juste lent mais m'assure que tout le monde ai bien sa chance d'intervenir logiciellement au moment de l'injection des donnée ?
La réponse que j'aurais apporté à ce genre de problématique c'est que bien souvent l'outil de base est mal choisi, et dès ce moment, avant même qu'une seule ligne du logiciel existe, ce choix aurait pu permettre d'éviter d'avoir se poser ces questions là.
Puis, pour revenir au XML, utiliser du XPath, sérieusement ? Pour des très gros imports, si tu sais ce que tu fais et que tu connais le schéma, il faut mieux utiliser un lecteur séquentiel, comme l'API XMLReader, qui va juste être incroyablement plus rapide et ne pas consommer de mémoire, là où les implémentations basées sur la libxml2 (c'est à dire toutes en PHP, sauf l'API XML(Reader|Writer)) nécessitent de charger le fichier XML intégralement en mémoire, et en profitent pour passer une phase d'autocorrection du contenu (si si, ça le fait, et même plutôt bien).
Bref, les performances ça se prépare en amont: