Taille du résultat de mysql_store_result()

Hello,

je ne suis pas développeur C et ne me souviens que des rudiments du langage, donc veuillez m'excuser si ma question est "toute bete".

Actuellement j'ai un code de ce genre :

Code:

---

my_result = mysql_store_result( xxx );

---

J'aimerais tout "simplement" pouvoir récupèrer la taille occupée en mémoire par "my_result". Enfin... il my_result n'est qu'un pointeur vers un élément de type MYSQL_RES, si j'en crois ceci :

Code:

---

MYSQL_RES *mysql_result;

---

Comment puis je procéder ?

Je ne sais pas si cela peut aider, mais d'après la doc MySQL mysql_store_result() utilise malloc().

Voilou, merci d'avance

Salut,

J'utilise souvent l'API MySQL et je pense pas qu'il y ait un moyen de connaitre la consommation mémore d'un result set obtenu avec mysql_store_result.
Ce qui est sur c'est qu'un tel result set contient toutes les lignes du resultat du SELECT, donc tu dois pouvoir estimer la consommation à partir de la longueur des chaines dans chaque champ de chaque ligne.

mm, ça ne m'arrange pas vraiment :roll:
En gros je dois faire un fetch de toutes les lignes pour incrementer un compteur de "sizeof()" sur chaque champ, c'est bien ça ?

Cela me semble un peu lourd comme traitement

Citation:

---

Envoyé par Kioob

mm, ça ne m'arrange pas vraiment :roll:

---

Pourquoi as-tu besoin de la taille ?

J'ai une machine hébergeant de nombreux clients "gratuitement" (plusieurs milliers de sites), et forcément dans le tas il y a des scripts très mal codés à base de :

Code:

---

1 2	$res = mysql_query( "select * from table_des_messages" ); $nb_msg = mysql_row_nums( $res );

---

Sur une table de 400Mo, cela fait des ravages ensuite coté Apache.

L'idée est donc de modifier l'extension mysql de PHP afin d'y tracer ce genre de choses.

Dans tous les cas ce n'est pas sizeof qu'il faut utiliser sur les champs d'un MYSQL_ROW, ya fort à parier que MYSQL_ROW n'est qu'un "char **". Donc "sizeof(row[n])" ne renverrait certainement pas une information interessante.

Par contre "strlen(row[n]) + 1" oui, mais pas forcément... il n'est pas dit que ce qui contient les chaines dans les champs de chaque MYSQL_ROW occupent juste ce qu'il faut pour y faire tenir la valeur (ça pourrait être plus)

Et de toute façon, si on ne compte que les longueurs des chaines, il manque également la taille des MYSQL_ROW eux meme, et d'autres données internes. Ca serait qu'une estimation.
A moins d'analyser la structure interne des MYSQL_RES et MYSQL_ROW, je pense que c'est pas possible, et même ce ne serait pas une bonne idée car susceptible de changer entre les versions de MySQL

D'un autre coté, si j'ai une estimation à + ou - 10%, ça me va déjà très bien.

Si je peux repérer tous les scripts qui chargent plus de 5Mo de données en mémoire, je serais déjà heureux ;)
(j'ai déjà tenté du coté de la fonction PHP memory_get_peak_usage(), mais la mémoire allouée aux résultats MySQL n'y est pas compté)

J'ai peut être une piste... pas forcément idéale non plus mais :
dans MYSQL_RES il y a "data" de type MEM_ROOT, qui pointe à priori sur une liste chainée de blocs mémoires. Et pour chacun la taille est indiquée.

J'ai également trouvé dans les sources mysql un exemple de code parcourant cette liste en un seul "for". Je tente de compiler ça (j'ai encore un peu de mal), et je verrais ce que ça donne...


PS : et si ça ne fonctionne pas je me contenterais du "row_count", qui évitera déjà quelques soucis

Et bien cela fonctionne. Avec "mysql_result" étant de type MYSQL_RES ( retourné par la fonction mysql_store_result() ) cela donne :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

MYSQL_DATA *data; MEM_ROOT alloc; USED_MEM *next;   unsigned int result_size;   data = mysql_result->data ; alloc = data->alloc ;   result_size = alloc.block_size ; for (next = alloc.used; next; next= next->next ) { result_size += ( next->size - next->left ); }

---

Voila, je ne sais pas si le résultat est exact à l'octet près, mais il est très très proche de ce que je cherchais (et en l'occurance, le script PHP dont je parlais bouffe bien 440Mo).

Ca m'interesse, merci
Cela dit, ca va un peu à l'encontre de la philosophie des types abstrait où on est pas senser fouiller dans la structure interne des objets.

Entièrement d'accord, et j'avoue que j'aurais préféré faire autrement :P

Là en cas de changement de "format interne" coté MySQL, je me retrouve avec un client qui ne compile plus, alors que c'est normalement indépendant.