Cout de l'allocation dynamique

Bonjour,

Je voudrais avoir des précisions sur le cout de l'allocation dynamique d'une tableau 2D de la taille d'une image ( disons 640 * 480 ) en terme de temps.

Mon probleme est le suivant, ma fonction a besoin d'un tableau temporaire pour son traitement. Le plus efficace serait de l'allouer dynamiquement une fois pour toutes dans la fonction appellante et de le passer en parametre a chaque appel. Mais je ne trouve pas ca propre pour une fonction réutilisable.

De quel ordre est donc la perte en comparaison à la meme fonction allouant dynamiquement son tableau a chaque appel... Mieux, en comparaison a la meme fonction allouant une fois un tableau static?

Rien que de remplir chaque pixel prendra déjà 100x plus de temps que de les allouer. Tu es sûr que c'est sur le temps d'allocation de la mémoire que se situe le problème (pour peu qu'il y en ait un) ?

Non, il n'y pas de probleme, c'est une question a titre informative. On entend toujours ca et la des remarque sur l'allocation dynamique ou sur l'utilisation de variables static, alors je me pose naturellement des questions.

Merci

bah, essaye de faire un benchmark, tu verras bien....
Ca prend "logiquement" plus de temps de faire de l'allocation dynamique, parce qu'à chaque fois tu te coltines la recherche d'un bloc à allouer, la mise à jour de la mécanique nécessaire pour l'allocation, etc...
Alors qu'en static, il n'y a pas tout ça.
Pour le quantifier, c'est difficile, ça dépend de la taille du bloc, de l'OS, de la fragmentation de la mémoire, etc....
Donc, pour avoir un ordre d'idée, fais un test.

Pourquoi tu veux faire de l'allocation dynamique ?
Pourquoi ne pas déclarer un tableau à la place ?

Citation:

---

Envoyé par tut

Pour le quantifier, c'est difficile, ça dépend de la taille du bloc, de l'OS, de la fragmentation de la mémoire, etc....

---

Et aussi du compilateur et des instructions avant et après et de l'état de ton processus au moment de l'appel et du sens du vent et de l'age du capitaine. L'optimisation que tu proposes est à un niveau tellement bas qu'il vaut mieux attendre de voir si ça freine trop le reste de ton programme.

L'optimisation prématurée, c'est maaaaaaal. Plus sérieusement, tu risque de perdre en clarté du code pour optimiser au maximum un poil de mouche qui ne sert à rien.

Citation:

---

Envoyé par roulious

L'optimisation prématurée, c'est maaaaaaal. Plus sérieusement, tu risque de perdre en clarté du code pour optimiser au maximum un poil de mouche qui ne sert à rien.

---

non monsieur, Tut a parfaitement raison ; faire des allocations continuellement cela fragmente la mémoire .
Il faut une bonne fois pour toute allouer le bloc mémoire

Citation:

---

Envoyé par mat.M

Tut a parfaitement raison ; faire des allocations continuellement cela fragmente la mémoire . Il faut une bonne fois pour toute allouer le bloc mémoire

---

Cela peut fragmenter la mémoire : dans la mesure où on n'a absolument aucun moyen de contrôler les instructions générées par le compilateur, on ne sait pas ce qui se passe par derrière. De plus, harsh parle d'images plutôt petites par rapport à la quantité de RAM sur les machines actuelles et ne précise pas le but de son programme. Si il fait de l'acquisition en temps réel, ça peut éventuellement gêner. S'il fait du traitement d'images, le coût des algo est tellement supérieur à celui de l'allocation que la différence ne sera pas visible.

Si son programme tourne suffisamment vite par rapport à ce dont il a besoin, pourquoi aller essayer de gagner quelques milisecondes, qui risquent en plus d'introduire des bugs supplémentaires ?

Citation:

---

De plus, harsh parle d'images plutôt petites par rapport à la quantité de RAM sur les machines actuelles

---

Euh ça fait quand même près de 2 Mo...

Citation:

---

Envoyé par loufoque

Euh ça fait quand même près de 2 Mo...

---

Je travaille depuis un bout de temps sur des images médicales, donc je suis un peu biaisé. Pour moi, les images classiques font plus 200 ou 300 Mo que 2Mo. En admettant effectivement que son image soit stockée sur 48 bits (1.7 Mo par image), on est quand même loin des 256 Mo qui semblent être un minimum vital sur les machines actuelles.

Mais tout ça ne change rien à mon point de vue sur l'optimisation, puisque harsh parlait uniquement de temps (je suis têtu :) ) : tant que le programme tourne suffisamment, pas la peine d'optimiser. Par contre, si l'allocation prend trop de temps par rapport à ce qui est demandé, le fait de mettre le tableau en statique (dans la fonction ou ailleurs) pourra peut être aider. Mais mieux vaut profiler avant.

La gestion de la mémoire reste un fondamental.
Et même si ça peut aussi être un secteur d'optimisation en fin de développement, attendre ce moment là pour se poser la question de quelle méthode est la plus adaptée ne me parait pas être une façon très avisée de programmer.

En supposant que le problème soit avéré -- car un programme qui va vite dans un mur n'a que peu d'intérêts.

Le statique n'est pas une solution qui me plaise. A cause de la non ré-entrance -- OK, je bosse dans des contextes multi-thréadés et temps-réel

Dans les pistes:
- s'il s'agit d'allouer des zones de résultat, alors tu peux très bien passer un vecteur (ou autre type matriciel) en [out]. A chaque appel de la fonction, tu fais alors un resize. Avec éventuellement un clear avant si tu veux forcer la RAZ.

- s'il s'agit d'avoir des zones de travail temporaires énormes. Tu peux voir à utiliser et exploiter un pool de matrices images. Du coup, au lieu de faire un véritable new, tu vas à la place réutiliser un buffer qui n'a jamais été véritablement libéré.

- en alternative au pool, tu peux avoir des objets algorithmes qui maintiennent les grosses variables qu'ils utilisent pour les calculs intermédiaires. Ainsi, chaque thread peut avoir son propre objet algorithme, ce qui offre une réentrance partielle, mais généralement suffisante.