Bonjour,
Je viens de tomber sur votre site par hasard et je lis cet article
"http://www.vulgarisation-informatique.com/include.php"

Et je lis ca :
"Il faut savoir lorsque l'on utilise ces fonctions qu'une inclusion de fichier est un accès supplémentaire au disque dur et que cela ralentit donc l'exécution du script. Je vous conseille donc de n'utiliser ces fonctions que lorsque vous avez vraiment besoin d'inclure un fichier. Si possible regroupez tout votre code inclus (venant de plusieurs fichiers) en un seul fichier à inclure, ce sera autant de temps de gagné pour PHP."

J'ai bondit et je me suis inscrit juste pour réagir a cette remarque.
C'est une hérésie de considérer de faire des trucs dégueulasses en un seul fichier juste
pour une histoire de supposées performances. J'aurais plutot tendance à conseiller
d'user et d'abuser des includes pour fragmenter de gros fichiers en des entités logiques et atomiques (c'est un truc qu'on appelle la modularisation dans l'informatique ...)

En informatique, c'est une règle d'or :
On commence par faire un truc qui marche et qui est propre, bien designe et lisible.
Ensuite si ca nous chante on fait de l'optimisation de performances.

En outre, on gagne toujours des clopinettes a faire ce genre de hack inutiles (genre "echo" au lieu de "print", ou ce genre de saloperies). Une optimisation de code, c'est des caches, un algo bien pensé, des access persistants aux databases, etc, ...

De plus les "access disques" comme vous les appelez n'ont rien de couteux. Ca fait belle lurette que tous les OS ont des filesystem avec des systemes de cache performants. Les access de fichier régulièrement demandés (comme sur un serveur web) se font tous en mémoire vive.

Désolé d'être aussi sec dans le ton mais votre site arrive en plus en première position sur google pour la requete que j'ai faite ()je me demande comment c'est possible), et ca me rend malade d'imaginer que des débutants puissent se mettre de telles idées dans la tête.

J'espère que la remarque sera retirée au plus vite.

Raphael

Salut,

pas grave que tu le prennes comme ça j'ai fait plusieurs benchs, ce n'est pas une hérésie. Il est évident qu'il faut faire des includes lorsque ton code devient hyper lourd (du genre du as 150 ko de code, il est important de le fragmenter en includes). Ce que je voulais dire par là de part mon message, c'est que de voir des codes du style
<?php include 'header.php'; //blabla include 'menu.php'; //blabla include 'footer.php'; //blabla ?>

c'est complètement inutile et coûteux en perfs. Tu as benché ce que prenait un include ? tu sais ce qu'est la montée en charge ?

cdvddt a écrit :

Je suis d'accord, je n'ai pas fini de faire des articles (je dois faire la section MySQL, et un article sur l'optimisation est prévu). Seulement pour faire un article sur de l'optimisation d'algo c'est pas une page qu'il me faudrait mais des dizaines. Désolé...

cdvddt a écrit :

Sur un hébergement mutu ? MDR (cf plus haut)

cdvddt a écrit :

Je suis loin d'être un débutant en PHP (à mon tour de me la péter...)

cdvddt a écrit :

Certainement pas Je sais ce que j'ai écrit et je le laisserai.

Bonne soirée,

Antho

cdvddt, on ne se connait pas, mais je me permet de te recommander de créer un programme de bench :

un programme de bench entre deux codes php

un programme de bench entre un programme php et un programme C

Ce qui te permetra de conclure que la vitesse, en php, c'est un facteur non négligeable, et que les astuces d'antho sont vraiment interessantes...

Je me suis mal exprimé sur l'article et son post prouve qu'il n'a pas bien compris ce que je voulais écrire, mon astuce de regrouper en un seul fichier ne concerne que les petits fichiers (cf mon exemple dans mon post précédent) et je suis entièrement d'accord sur le fait qu'il est stupide de faire par exemple 1 Mo de code en une page, c'est complètement stupide et coûteux en perfs, il faut trouver un juste milieu entre le nombre trop important de fichiers qui va diminuer les perfs et un nombre de fichiers trop faible. Je vais éditer mon article pour clarifier ce point.