[C/C++] Coût d'une allocation mémoire

Coût d'une allocation mémoire [C/C++] - C++ - Programmation

Marsh Posté le 05-11-2009 à 21:10:44    

Bonjour à tous,
 
j'ai été confronté récemment à la problématique de l'impact que peut avoir l'allocation dynamique de mémoire sur les performances d'un programme.  
 
Je ne veux pas faire mon vieux croûton, mais à l'époque où l'on m'a enseigné le C/C++ (entre 96 et 99), on m'a clairement expliqué que l'allocation, c'est pas gratuit, et qu'il faut éviter d'en faire à la volée surtout s'il s'agit de données de taille considérable, comme des images par exemple. J'ai donc pris l'habitude de pré-allouer autant que possible la mémoire que je sais nécessaire, et de travailler ensuite principalement par pointeurs.
 
Aujourd'hui un de mes collaborateurs m'a montré son code de lecture vidéo utilisant principalement des références, de sorte qu'à chaque nouvelle image, il alloue un nouvel objet (donc environ 640x480x4 octets) qui sera détruit une fois l'image traitée, puis réalloué à l'image suivante etc.
Evidemment j'ai tout de suite tiqué, mais il m'a soutenu que le surcoût d'une allocation était négligeable, et à vrai dire quelques tests rapides et naifs du genre "boucle infinie" n'ont pas démenti la chose. Donc même si je ne trouve pas "élégant" de jouer ainsi avec la mémoire, pourquoi pas, mais ça va quand même à l'encontre de tout ce que je croyais.
 
Je me pose donc des questions :  
est-ce que j'ai mal appris mes cours ?  
ou bien le progrès du matériel ou des compilateurs a fait disparaître ce qui était une contrainte à l'époque ?  
ou bien il y a une faille dans les tests et il y a bien un inconvénient à abuser des new/delete ? (après tout un "hello world" en boucle infinie, ce n'est pas la même chose qu'un vrai programme qui brasse de la donnée...)
 
Si des personnes versées en gestion bas niveau de la mémoire pouvaient m'éclairer sur le sujet, j'en serais bien reconnaissant.
 
Merci d'avance. :)

Reply

Marsh Posté le 05-11-2009 à 21:10:44   

Reply

Marsh Posté le 05-11-2009 à 21:20:00    

bah, je pense que ce qui se passe est que comme il delete.new dans sa boucle sans rien a coté, l'allocateur reutilise le bloc precedemment dessaloué. Et comme ce qui coute, c'est la recherche + marquage du bloc, ca va assez vite.
Fait un test en allouant dans une boucle puis en desallouant dans une autre tu verras la différence.

 

Ah et 640x480x4, c'est pas enorme.


Message édité par Joel F le 05-11-2009 à 21:22:22
Reply

Marsh Posté le 05-11-2009 à 21:37:25    

Puis, il faut voir ce qu'on compare.  Par rapport à une addition ou une multiplication, une allocation mémoire, c'est coûteux.  Par rapport à du traitement d'image (a priori plus d'un calcul par pixel...), ce ne l'est plus.


---------------
The truth is rarely pure and never simple (Oscar Wilde)
Reply

Marsh Posté le 05-11-2009 à 21:38:27    


Clair, 640x480x4, c'est 1.2Mo. Sur une machine avec 2Go de RAM, c'est 0.05%, soit que dalle.
 
Au pire à force de faire des allocations n'importe comment, tu risques de fragmenter ton espace mémoire, ce qui risque de pénaliser tes accès, à cause de cache-miss du TLB. Mais à mon avis, ça va passer complètement innaperçu, en général à cause des accès disque (il y a en toujours) et/ou communication réseau. Quand ce n'est pas Windows qui se décide à swapper le noyau parce qu'il n'y a plus que 95% des ressources disponibles.
 

Reply

Marsh Posté le 05-11-2009 à 22:23:28    

Merci pour vos réponses... c'est sûr que 1.2Mo de données, ça avait plus d'impact quand les PC avaient 32M de RAM ! (voire moins en embarqué...).
J'hésite quand même à encourager la débauche d'allocations (surtout qu'on commence comme ça, et après on se met à créer des images partout dans les traitements...), mais bon dans ce cas précis, et tant que ça tourne sur un PC, il n'y a peut-être pas de raison d'en faire un drame.
 
Je vais quand même faire quelques tests plus poussés, pour être sûr. "Y a pas de petits profits" comme on dit...

Reply

Marsh Posté le 06-11-2009 à 03:01:52    

Dans l'absolu, si tu peux pré-allouer les buffers de travail, te retiens pas non plus.

Reply

Marsh Posté le 06-11-2009 à 08:11:48    

bjone a écrit :

Dans l'absolu, si tu peux pré-allouer les buffers de travail, te retiens pas non plus.


Exactement.

Reply

Marsh Posté le 22-01-2010 à 00:08:13    

 

Le temps d'allocation mémoire est meilleur pour l'allocation statique simplement car il n'y as pas d'allocation à proprement parler.
Quand la variable est statique l'espace est reservée dans le binaire et quand la variable est automatique l'espace est pris dans la stack par un simple offset d'adresse.

 

Evidement ces 2 espaces sont limitées et on ne peux pas en abuser. Il vaut mieux tenter de réutiliser la mémoire déjà allouer quand on sait qu'on en aura encore besoin. Le plus performant c'est toujours le l'algo le plus astucieu :)

 

Autrement on ne peux que constater que même pour les programmes de calculs intensifs jusqu'a 30% du temps est passé dans l'allocation dynamique...


Message édité par Harkonnen le 22-01-2010 à 14:30:33
Reply

Marsh Posté le 22-01-2010 à 14:03:52    

- On parlais pas d'allocation statique.
 
- Faire une recherche sur le forum sur tous les topic concernant les problèmes d'allocations, poster un MOTO afin de pouvoir placer une double référence à un produit commercial et avoir une indexation google améliorée ça s'appelle du spam.
 
- Si tu veux participer au forum, tu te crée un compte perso, pas au nom de ta boite.


Message édité par bjone le 22-01-2010 à 14:10:17
Reply

Marsh Posté le 22-01-2010 à 14:31:39    

+1, 2 topics remontés uniquement pour faire du spam (dont un de plus de 2 ans), faut pas abuser.
aller simple chez nos amis multicolores


---------------
J'ai un string dans l'array (Paris Hilton)
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed