Zend FR

Autoload ou pas, si tu as des librairies qui ont des classes de même nom, il y a des conséquences... L'autoload n'a pas grand chose à voir la dedans... ce n'est jamais qu'un moyen automatique de faire include....

la procédure d'autoload, c'est toi qui l'écrit. Donc sauf si tu ne maitrises pas ce que tu écris, je ne vois pas comment tu ne maitrises pas ce que fait l'autoload.
Bref, moi j'utilise l'autoload et je n'ai aucun pb et ce n'est vraiment pas un petit site (environ 10 000 classes). J'y trouve une simplification du code et cela m'évite de charger des classes dont je n'ai plus besoin après évolution.
Mais chacun gère ses problèmes à sa manière hein...

Bah, les perfs, c'est assez facile de faire le pour et le contre.
Tu vas avoir un overhead du a l'autoload puisque tu as une procédure qui va se charger de retrouver le fichier et de faire l'include a ta place. C'est d'autant plus vraie si tu fais tes includes toi même. Ca l'est beaucoup moins dans le cas du ZF puisque tu passe par Zend_Loader::Loadclass qui est la meme fonction qui serait exécuter de facon automatique par l'autoload. Donc ici, quasi pas de gain si ce n'est le déclanchement de l'autoload mais qui est effectué par le core php et dont le coût est vraiment négligeable.
En revanche, il y a aussi des gains en perfs, j'en vois au moins 2, un sur et un probable :
1/ Avec l'auto l'autoload, tu peux systématiquement te contenter d'un include/require au lieu d'include_once/require_once. Même si à partir de la 5.2, il y a eu un gros effort sur les "xxx_once", ils ont toujours un  cout en ms nettement supérieur à la version non "once". De même, ils consomment plus de ram puisque il faut gérer un index des fichiers inclus. Ca, c'est un gain acquis certain et quantifiable.
2/ Si tu es sur un gros projet qui évolue sur du long terme, la gestion des inclusions devient un vrai casse tête et rapidement, on fini par inclure beaucoup trop de chose par apport a ce qui sera utilisé réellement. Car pour une page X tu aura besoin de tel ou tel fichier mais pas pour la page Y, sauf que les includes sont fait dans un fichier commun, du coup, tu pénalises la page Y. Idem, tu vas certainement utiliser des classes de débug lors du dev et il y a fort a parier qu'a un moment ou un autre, tu oubliera d'enlever l'include. Elles ne seront plus utilisées mais toujours inclues. Pareil pour les évolutions, besoin de tel classe a un moment puis plus après une évolution mais les includes restent. Ici le gain est néanmoins beaucoup plus difficile a quantifier

Quand on fait un peu de profiling php, on se rend vite compte que les includes coûte cher. Si tu veux, tu peux faire un truc tout bête, fait en fin de page un print_r(get_included_files()), tu seras certainement surpris par le nombre de fichiers inclus et tu trouvera peut être même des fichiers qui sont inclus et que tu avais oubliés et dont tu sait ne plus.

Maintenant, il faut aussi remettre les choses pour ce qu'elle sont. Si tu as des problèmes de perfs, ce n'est pas l'autoload qui changera quelque chose. Php, c'est gentil, mais sans un système de cache (op-code et page partiel ou total), tu ne peux pas attendre des perfs mirobolantes sur un site a forte fréquentation. Et c'est via un cache bien pensé que tu peux obtenir de très bonnes perfs même sur un serveur moyen. Et php n'est pas la seule solution pour améliorer les perfs, il y a tout ce qui se passe en amont avant d'avoir la main sur php. Je suis justement en train de travailler sur la phase final d'optimisation du nouveau site que nous préparons. Il est basé sur le ZF et dès qu'il sera online, je donnerais l'url.

Bah je ne cherche pas a te convaincre non plus, moi j'y trouve mon compte car je n'ai plus a gérer les includes et je suis absolument certain a tout moment ne ne jamais inclure un fichier dont je n'aurait plus besoin. Et même avec une bonne gestion des includes, je n'aurait jamais pu dire cela avant.
Quand a utiliser plusieurs frameworks ou librairie ayant des noms de classes identique, c'est forcement contraignant. Déjà il faut faire un choix entre la fonctionnalité 1 et 2 tout en sachant qu'on ne pourra jamais avoir les 2 (perso, quand j'ajoute une lib, j'aurai bien du mal a exclure les autres).  Ceci étant dit, si toi, tu es capables d'identifier quel lib utiliser, pourquoi ne serait tu pas capable de coder la logique qui identifie ce besoin ?

Je voie au moins 4 possibilités :
- Tu définie une procédure d'autoload pour chaque framework/lib et tu actives la procédure idoine  en fonction de tes besoins.
- Tu fais une seule procédure avec un flag d'aiguillage que tu gères en fonction de tes besoins.
- Tu fais plusieurs procédures toujours active et qui suivent un flag d'aiguillage (mix des 2 solutions précédentes)
- Tu peux aussi faire un aiguillage automatique en fonction de la présence de certaine classe  principale qui sont unique dans chaque framework.

bref, je ne pense pas que ce cas de figure serait bloquant s'il devait m'arriver d'avoir a utiliser 2 lib ayant des noms de classe identique, je serais en revanche beaucoup plus soucieux des conséquences éventuelles sur les caches d'op code...

Dernière modification par TiTerm (29-10-2007 09:28:33)

Tiens, ce 'débat' me rappelle la conférence qu'a donnée Derick au forum PHP AFUP il y a peu.
Le slide est dispo ici.
Derick a expliqué clairement le processus de l'inclusion de fichier, et des noms de fonction.
Il avoue lui même utiliser l'autoload, car le confort est très intéressant. Il a évidemment dit que ca avait des impacts sur les performances ( tout comme le _once {include ou require} ), mais qui ne sont pas énormes non plus.
Un cache opcode (tel APC dont on a eu une belle démo aussi {facebook}) sait très bien gérer ces problèmes là, à condition qu'il soit configuré correctement. ;-)