Effectivement, ça fait peur de voir que les include sont si lents.
Mais, mais, mais vous avez oublié un petit détail non négligeable qui peut (et de loin) renverser la balance : les outils de cache php (type eaccelerator, zend cache).
Refaîtes les comparaison lecture ficheir-unserialize / include en utilisant un cache (eaccelerator est gratuit :
http://eaccelerator.net/HomeFr?lg=fr).
A mon avis le include l'emporte haut la main.
Edit : Après réflexion, ça me semble logique que unserialize soit plus rapide que l'évaluation du code source. Tout est une question de "passes" (et vive les cours de compilation).
Lorsqu'on évalue un fichier source, il faut une première passe pour construire un arbre syntaxique représentant le code source (on vérifie donc au passage la bonne syntaxe du code). Pendant ce traitement, on ne peut pas encore préparer le code intermédiaire car on ne connaît pas le contenu du fichier avant de l'avoir parcouru entièrement. Pour l'exemple du tableau, on ne sait pas le nombre d'éléments avant la fin du fichiers.
Donc il doit faire au moins une nouvelle passe pour construire l'objet en mémoire à partir de l'arbre syntaxique généré.
A l'inverse, la sérialisation est une méthode de stockage, le code serializé n'est pas destiné à être lu ou écrit par l'utilisateur. Il a donc été optimisé pour son interprétation (et non son écriture).
Quand vous regardez du code serialisé, vous pouvez voir que chaque élément (objet, tableau, scalaire) est préfixé par son nom, sa taille. Cela permet à l'interpréteur de préparer la mémoire à l'avance et de tout faire en une passe (ou du moins, moins de passes qu'avec un eval). C'est clairement plus rapide. Alors oui le résultat donnes de plus gros fichiers, mais c'est le prix d'un plus grande rapidité, et sans ça la serialisation n'aurait pas d'intérêt.
Le seul autre inconvénient c'est que contrairement à du code source ça n'est pas lisible. Mais en même temps, ça n'est pas non plus le but.
