Pourquoi diable configurer l'autoload de manière à ce qu'il puisse trouver une classe... qui n'est que rarement utilisé ?? Sauf cas très spécifique (je cherche encore), en effet, il est rare qu'on envoi un mail à chaque visite d'une page du site. Par exemple sur un site e-commerce, on va envoyer un mail lors de la confirmation de commande. Et cette page de confirmation de commande est une page rarement "visitée", en regard du nombre de "hits" sur les pages permettant de parcourir le catalogue produit par exemple.

Admettons que sur 100 000 page visitées, un seule page va envoyer un mail. Cela veut donc dire que, dans 99,999% des cas, la préparation de l'autoload pour trouver les classes de swiftMailer, ne sert strictement à rien. Déjà à ce niveau, on perd en temps d’exécution (celui du chargement de l'autoloader de swiftmailer), même si c'est quelques milli-secondes (allez, disons micro-secondes), et on perd en occupation mémoire, même si c'est quelques dizaines d'octets. Cependant, quand tout ça est multiplié par le nombre de requêtes par jour ou simultanée, ça peut commencer à devenir significatif.

Alors on me répond, "oui mais bon, c'est mieux que de faire un require pour chaque page". Certes. Mais n'empêche, rien que de charger l'autoload, ça bouffe du CPU et de la mémoire pour rien, à chaque page.

Et ce n'est pas tout. L'autoload de swiftmailer, une fois chargé, est rarement actif. Il va manger encore plus du CPU et de la mémoire que ce que je disais. Comment ? tout simplement, quasiement à chaque fois que PHP tente de charger une classe. Car lors de ce processus, PHP va demander à tout les autoloaders si ils ne veulent pas essayer de charger le fichier qui contient la définition de la classe qu'il demande. Quand un framework charge, rien que pour un projet vide, des autoloadeurs à tout va, qui eux même vont faire un, deux, dix, 20 tests sur le nom de la classe ou faire des manipulations de chaîne dans tout les sens sur ce nom de classe (un autoloader compatible PSR0, n'est pas anodin en ce sens...), tout ça prend du temps, forcément. Multipliez ça par le nombre de classes utilisées dans chaque page, et par le nombre de page chargée, le temps passé dans l'autoload commence à ne pas devenir anodin (vis à vis du "temps de latence" du framework dont parle Loic), avec une part significative des autoloaders pour les composants utilisées rarement. Et on en arrive a des perfs catastrophiques, même pour un hello world.

Bref, l'autoload, c'est bien, ça évite au développeur de faire des require/require_once dans tous les sens. Mais il ne faut pas en abuser.

Dans Jelix, voici ce que je fais :

  • pour les classes de jelix utilisées à chaque "page" ou presque : require. Utiliser l'autoload n'a pas de sens pour des classes utilisées tout le temps. Les classes sont chargées directement, PHP n'a pas à faire appel aux autoloaders.
  • pour les classes rarement utilisées : require. Le développeur va utiliser les classes en question une fois de temps en temps, il n'y a donc pas de raison de les déclarer pour l'autoload, Le développeur peut très bien prendre 10 secondes à écrire un require là où il en a besoin (ce qui n'empêche pas le fichier inclus de configurer l'autoload pour les classes que le développeur est alors susceptible d'utiliser). Il peut même utiliser l'objet jClasses pour indiquer de charger la classe de tel module, sans avoir à connaitre le chemin.
  • Pour toutes les autres, c'est à dire les classes utilisées souvent mais pas tout le temps : autoload.

On a ainsi un bon compromis entre performance et facilité de développement.

PS : l'utilisation de l'autoload pour toutes les classes dans SF2 n'explique probablement pas totalement les problèmes de performances...