Larry Garfield présente le nouveau gestionnaire d'inclusion de Drupal. Ce dernier, en version 6, représentait 50% du temps d'exécution d'un script Drupal : en bref, à chaque appel de page, Drupal passait la moitié du temps à inclure des bibliothèques, et l'autre moitié à s'exécuter.
Pour gagner en exécution, Larry a monté un gestionnaire dynamique : il analyse le code source des scripts PHP inclus, puis détermine les fichiers nécessaires pour exécuter cette page, en extrayant les fonctions. Puis, un cache d'inclusion est réalisé pour gagner du temps. Cela revient à un __autoload(), avec un peu plus d'intelligence.
Le démarrage d'un script est certainement l'un des endroits d'une application où il y a le plus à gagner. Jusqu'à présent, on incluait tout ce qu'il était possible d'inclure pour ne pas manquer de fonctions lorsque le temps viendrait de les utiliser. Mais cela revient à cuire un gateau complet, et n'en manger qu'une petite portion : le reste est gaspillé.
Avez-vous d'autres stratégies pour réduire vos phases de lancements de scripts ?
- Drupal 7 gets introspective code registry
- Drupal Registry
Pour gagner en exécution, Larry a monté un gestionnaire dynamique : il analyse le code source des scripts PHP inclus, puis détermine les fichiers nécessaires pour exécuter cette page, en extrayant les fonctions. Puis, un cache d'inclusion est réalisé pour gagner du temps. Cela revient à un __autoload(), avec un peu plus d'intelligence.
Le démarrage d'un script est certainement l'un des endroits d'une application où il y a le plus à gagner. Jusqu'à présent, on incluait tout ce qu'il était possible d'inclure pour ne pas manquer de fonctions lorsque le temps viendrait de les utiliser. Mais cela revient à cuire un gateau complet, et n'en manger qu'une petite portion : le reste est gaspillé.
Avez-vous d'autres stratégies pour réduire vos phases de lancements de scripts ?
- Drupal 7 gets introspective code registry
- Drupal Registry
-
Auteur
-
Origine
