par
Sékiltoyai » 23 févr. 2008, 01:20
J'ai retesté un peu et c'est plus incompréhensible encore.
Déjà le test que tu m'as donné Hubert donne des résultats 10 fois plus lourds que le mien, c'est incompréhensible quand on sait que ce script est moins lourd et qu'il assigne une quantité de données plus faible (4 octets, 8 au maximum pour un entier contre les 7,5 octets en moyenne des chaines).
Ensuite, titerm, bien entendu php a besoin de place supplémentaire pour gérer les données, c'est inhérent à tout langage interprété, il faut stocker avec la variable des meta-informations comme son type, pour php le nombre de références, ou encore sa portée. Mais toutes ces informations sont numériques (entiers ou adresses) et, dans mon cas, au mieux 160K de méta-données pour 16K de données réelles (en comptant le nom de la variable), ca me paraît vraiment énorme.
Après, dire que le garbage collector n'a pas fait son boulot, c'est possible, mais si on prend ton test Hubert, tu n'utilises aucune variable supplémentaire et on ne peut pas prétexter une non destruction des variables non utilisées.
Bref, pour l'instant je n'ai pas été convaincu qu'il n'y a pas un très grave problème d'optimisation au niveau du noyau php. En l'occurence une table de hashage (et encore, si c'est la structure de donnée qui est utilisée) qui prend 10 à 100 fois la taille qu'elle devrait prendre, ca me choque, et autant je ne me demande plus si php mesure mal la mémoire, autant, maintenant, je me pose la question du problème de mémoire, voire même des fuites mémoires au niveau du noyau ou bien en aval dans les fonctions utilisant emalloc.
J'ai retesté un peu et c'est plus incompréhensible encore.
Déjà le test que tu m'as donné Hubert donne des résultats 10 fois plus lourds que le mien, c'est incompréhensible quand on sait que ce script est moins lourd et qu'il assigne une quantité de données plus faible (4 octets, 8 au maximum pour un entier contre les 7,5 octets en moyenne des chaines).
Ensuite, titerm, bien entendu php a besoin de place supplémentaire pour gérer les données, c'est inhérent à tout langage interprété, il faut stocker avec la variable des meta-informations comme son type, pour php le nombre de références, ou encore sa portée. Mais toutes ces informations sont numériques (entiers ou adresses) et, dans mon cas, au mieux 160K de méta-données pour 16K de données réelles (en comptant le nom de la variable), ca me paraît vraiment énorme.
Après, dire que le garbage collector n'a pas fait son boulot, c'est possible, mais si on prend ton test Hubert, tu n'utilises aucune variable supplémentaire et on ne peut pas prétexter une non destruction des variables non utilisées.
Bref, pour l'instant je n'ai pas été convaincu qu'il n'y a pas un très grave problème d'optimisation au niveau du noyau php. En l'occurence une table de hashage (et encore, si c'est la structure de donnée qui est utilisée) qui prend 10 à 100 fois la taille qu'elle devrait prendre, ca me choque, et autant je ne me demande plus si php mesure mal la mémoire, autant, maintenant, je me pose la question du problème de mémoire, voire même des fuites mémoires au niveau du noyau ou bien en aval dans les fonctions utilisant emalloc.