Les includes

Salut,


SVP quelqu'un peut-il m'expliquer la bonne pratique concernant les include?

Je m'explique: j'ai une page longue avec des bouts de codes PHP eux assez longs, sur certains forums il est écrit qu'il vaut mieux, les mettre dans un fichier à part et les appeler via l'include comme suit:

<?php include '/php/bout-de-code.php' ?>

Je me doute que c'est plus pratique pour la maintenance mais en général j'essaie d'indenter correctement et je m'y retrouve. La question est: est-ce que cela va me simplifier la vie d'avoir 50 petits fichiers PHP à part appelés avec l'include dans ma page et surtout est-ce que cela joue sur la performance générale?
Modifié par jmlapam (29 Mar 2012 - 18:34)

La première chose à prendre en compte, c'est que les include peuvent économiser des compilation. Exemple :

if($truc==3)
{
    // 200 lignes de code
}
else
{
    // 200 lignes de code
}

Dans cette exemple, on a 400 lignes de code compilées à chaque fois et seulement 200 utilisées. Donc 200 lignes compilées pour rien à chaque chargement.

if($truc==3)
{
    include('truc3.php');
}
else
{
    include('else_truc3.php');
}

Là, On a plus que 201 lignes compilées à chaque chargement dont 1 non utilisées, c'est autrement plus optimisé

Ensuite, include est bien entendu un outil indispensable pour organiser tes fichiers et là, il s'agit de faire en sorte que ce soit bien rangé avec des noms clairs et nul doute que ça va t'aider.

Enfin, à toi de trouver la bonne proportion. Si tes includes font en moyenne 5 lignes, c'est que t'as trop découpé, s'ils en font 500, il y a des chances que tu puisses découper davantage.

PS: 1+1=10 non ?
Modifié par KyleKatarn (29 Mar 2012 - 19:14)

Merci à toi,

Je comprends mieux l'affaire, j'avais peur que cela ne pèse sur le chargement de la page mais apparemment pas du tout, au contraire même.

EDIT: sinon "1+1=11 et ça c'est beau" comme a dit le philosophe...
Modifié par jmlapam (30 Mar 2012 - 01:29)

C'est aussi en général que les parties coupées seront insérées sur plusieurs pages. Ce qui est plus intéressant pour la maintenance que l'indentation

Pour les performance, à moins de travailler sur de lourds projets (applicatif, core de CMS, etc.) l'optimisation des includes pour le temps de chargement n'aura pas d'influence sensible.

p.s: 1+1, ça existe.

Dites-moi si je me trompe, mais les include n'augmentent en rien le poids de la page html finale que le client doit charger non ? Puisque c'est bien php qui procède aux includes, et qu'un cache ne servirait à rien...

Dès lors, malgré leur intérêt pratique plus que certain, les includes ralentissent au contraire le chargement, puisque : le poids final est le même, mais le serveur a du travailler plus. Peut-être je me trompe...

Non, il manque des données à ton calcul : la compilation. À ce niveau, des programmes de cache existent : APC par exemple qui permet de garder en mémoire le PHP compilé. Ce qui n'empêche pas qu'on puisse limiter la compilation au strict nécessaire. Comme expliqué dans mon exemple si on a 500 lignes dans un if et 500 dans son else, on compile 1000 lignes, le temps de compilation de ces lignes est plus que probablement supérieur au temps pris par un include.

On a donc, sans include :
Compilation de 1000 lignes puis exécution de 500 lignes.
Avec include :
Compilation de 2 lignes (les includes), exécution d'une ligne (l'include dans le if ou le else), compilation de 500 lignes, exécution des 500 lignes.

La deuxième est plus rapide et plus les fichiers inclus sont gros plus la différence est nette.

Bien sûr, ça vaut si les includes sont dans des conditions (switch, if, ternaire...)

kustolovic parlait aussi des fichiers réutilisable par plusieurs scripts. Un fichier formulaire.php par exemple utilisé par toutes les pages contenant un formulaire. Si on a un système de cache tel qu'APC, alors formulaire.php n'aura besoin d'être compilé qu'une seule fois et là aussi, il en résulte un gain de performances.

Donc les includes correctement manipulées optimisent les performances côté serveur.

Evidemment, ça ne change pas la vie du client, ce qui est transféré est strictement identique et la différence de temps de chargement reste insensible à moins d'avoir vraiment des fichiers énormes.

Mais, il y a d'autres limite : la RAM et le processeur du serveur qui limitent le nombre de demandes simultanées et donc plus on traite vite les demandes plus on peut en traite.

Si vous souhaitez vraiment optimiser vos pages, faites un code qui repose sur du language machine plutôt que sur de l’interprété. Bon moi je préfère faire mes site en php plutôt qu'en C, mais c'est toujours possible...

Pour être plus réaliste et parce que je ne code pas facebook ou youtube, (eh oui, c'est pas moi ) il faut se rendre compte que chaque ligne de php demande plus de ressources de traitement au serveur, c'est le principe même du php, il ne faut pas paniquer pour chaque petite ressource que l'on ajoute. De plus, comme dit précédemment, lorsque il y a déjà beaucoup de code php, include permet de limiter l'utilisation de ces ressources.

KyleKatarn c'est intéressant ce que tu dis, je ne connaissais pas ces méthodes de cache. Alors c'est vrai que certainement la compilation des fichiers php peut être améliorée. Mais au niveau des requêtes http pour le client, on est bien d'accord que dans tous les cas, le temps d'attente est toujours plus grand, puisque lui ne cache rien (et qu'avec cache php ou pas, il faut quand même appelé l'interpréteur).

Par contre, pour ton exemple, je pensais (mais j'avoue que je ne me suis pas renseigné) que les include était remplacé dès la compilation du code.

EDIT : c'est-à-dire que je pensais que la procédure était :
à la compilation : appeler la page à inclure (éventuellement la compiler), et insérer
à l'exécution : y'a plus que du "texte"
alors que toi tu dis que ça serait plutôt
à la compilation : fabriquer une règle d'insertion
à l'exécution : importer la page (éventuellement à compiler)
Intéressant
Modifié par justin.dekeyser (02 Apr 2012 - 13:40)

justin.dekeyser > Bien sûr que non. Avec 500 lignes compilées en moins, le temps d'attente est plus court ne serait-ce que de quelques millisecondes.

Si un script n'a pas besoin de l'include (qu'il est dans une condition valant false par exemple), le fichier ne sera même pas lu.

Si tu es aussi sceptique, tu n'as qu'à faire des benchmarks avec des bons gros fichiers pour avoir des différences significatives (par contre, il faut faire attention, un benchmarks écrit en PHP ne tiendra pas compte de la compilation du fichier dans lequel il est écrit, logique).

Et pareil, fais un truc style :

<?php
if(false) include('fichier.php');
?>

Et regarde si la date de dernier accès du fichier est modifiée, normalement non.

Ah mais je te crois volontiers pour ce qui est de la compilation et de l'augmentation des perf avec un système de cache !

Pour être très clair par rapport à ta question sur le temps de chargement de la page.

Pour un code de 10 000 sans include, si le client met en moyenne 2000 ms pour charger la page. Si on optimise avec un système d'include pertinent, le temps moyen de chargement de la page descendra à 1950 ms car PHP renverra la page plus vite.

Donc, on est loin de ce qu'on peut gagner en faisant des sprite, en compressant mieux, en minifiant, en différent les chargements des scripts JS etc. Mais en aucun cas, ça ne va ralentir le chargement, il ne faut pas s'en priver et surtout pas utiliser l'excuse de l'opti pour ne pas s'en servir, car c'est juste faux.

Niveau bande passante (bien qu'avouons-le aujourd'hui, on est beaucoup moins limités à ce niveau), ça ne bouge pas d'un octet. Quoique si on repart à 0 pour l'indentation dans les includes, on peut grapiller mais si on en est là, il existe des techniques plus efficaces pour alléger les transferts (compression Gzip, minification du HTML...)

En résumé, l'include, c'est tout bon, c'est comme le mouton
- Un tout petit peu moins de processeur
- Moins de RAM
- Un tout petit peu moins de bande passante
- Un tout petit peu moins de temps de chargement
- Moins de code (utilisation depuis plusieurs scripts)
Et surtout, dès lors qu'on s'en sert, qu'on aborde le MVC, qu'on fait un peu de POO, et en fait même dès lors qu'on sort du site vitrine de 3 pages, travailler sans include est juste inconcevable.

Intéressante discussion. Question subsidiaire.

Soit un site de 30 à 300 pages.
Pour minimiser le temps d'affichage complet de chaque page, vaut-il mieux :

1. Créer un seul gros include de fonctions de 60 ko que l'on charge dans chacune des pages et ensuite appeler les fonctions utilisées par la page.
ou
2. Créer 60 includes de 1 ko en moyenne, puis dans chaque page n'appeler que les includes nécessaires ?

Vaut mieux regrouper tes fonctions par thèmes dans des classes (une classe par fichier) et laisser l'autoloader de PHP les charger à la demande.

Si tu ne fais pas de l'objet, et que tu souhaites te passer de cette fonctionnalité très pratique, il est mieux de et plus simple d'essayer de regrouper:
par exemple:
1 fichier contenant les fonctionnalités de bases reprises presque partout,
quelques fichiers regroupant les fonctions par type d'utilisation.
1 fichier par page, si besoin, pour ce qui sera utilisé qu'une seule fois.

Si tu n'utilise que des méthodes statiques c'est pas vraiment de l'objet.

Merci jb_gfx et kustolovic pour toutes ces explications.