Je vérifiais un truc aujourd'hui, un script php qui envoie un large tableau vers un client JS (AJAX).

J'ai plusieurs modes d'affichage de ce tableau (json,print_r, var_dump et var_export). J'utilise le print_r pour mieux voir ce qui s'envoye, mais je trouvais ça fort lent, alors j'ai mis un timer sur à peu près tout le bazar.

Résultat, alors que print_r met de 8 à 12 secondes, var_dump 6 et var_export 5 (sur plusieurs essais), json_encode tourne autour des 33 centièmes.

json_encode demande sans doute moins de ressources pour afficher le contenu (pas de retours à la ligne, pas de formatage pour la lisibilité), mais je trouve ça quand même assez fun..

Ce serait intéressant de bencher cette fonction contre serialize() sur les mêmes données

Ca ne m'étonne pas plus que ça, j'ai remarqué depuis longtemps que les sorties de texte (en particulier en gros volume) sont plus coûteuses que la plupart des traitements.

Il faut aussi remarquer que print_r() et var_dump() ont pour vocation de servir au débugage uniquement, et donc n'ont pas les mêmes contraintes (ni sans doute les mêmes optimisations) de performance que le reste du langage.

Effectivement, tout comme Calimero, lorsque je debugge, j'attends une présentation et non pas une performance.

Du coup, avant de passer devant print_r et var_dump() (qui sont, pour moi, complémentaires), il va falloir s'accrocher

Effectivement, tout comme Calimero, lorsque je debugge, j'attends une présentation et non pas une performance.

Oh, je ne vous contredit pas ^-^ je voulais en fait m'assurer que le ralentissement était du à print_r, ou plutôt à autre chôse..

Du coup, j'ai fait quelques stats (3 résultats par méthode, ceci est une moyenne) :

print_r : 7.01055 sec.

serialize: 0.00487 sec.

json_encode : 0.02340 sec.

bon.. serialize tue tout..

essaie de forcer le passage du paramètre par référence dans tes tests. Si ça se trouve c'est simplement
que json_encode et serialize ont été écrites en forçant le passage du paramètre par référence, pour optimisation.