Pourquoi Visual Studio est lent sur la gestion de la mémoire?

Bonjour à tous,

Tout est dans le titre!
J'ai fait un allocateur linéaire pour optimisé les allocations mémoires.
Pour comparer les performances, je fais un benchmark sur 1 Go alloué via malloc, avec des insertions personnalisé (via "allocator") d'une classe de 28 octets pour 512Mo, soit 19173961 allocations.
Avec l'allocateur j'arrive à un résultat de 0.16 secondes pour toutes les allocations et pour le free de la mémoire.
A des fins de comparaison je fait la même chose avec 19173961 new qui me prends 0.91 secondes et autant de delete qui me prend.... bas je sais pas en faite.... au bout de 10 minutes j'étais même pas arrivé à 10 millions de delete et j'ai un bad_alloc sur après quelque Mo de new.
Mais ce comportement n'est que via Visual Studio. Lorsque je lance le programme hors Visual Studio, le tout ce fait en quelque secondes ( 1 à 2 secondes) sans aucune erreur.
Savez-vous pourquoi Visual Studio ralenti autant la gestion mémoire? sachant que je compare en Release.

Merci

De base, un allocateur mémoire est « généraliste ». Il est moyen en tout. Si tu alloues beaucoup de petits objets, un allocateur personnalisé peut apporter des améliorations de performance.

Attention, cela peut se faire au détriment de la sécurité : certains allocateurs, par sécurité, nullifient la mémoire qu’ils renvoient : ce ne sera plus le cas, sauf si ton allocateur custom le fait aussi. Ça peut être ou ne pas être un problème suivant les cas (dernier exemple en date :*heartbleed…).

Pour ce qui est de l’exécution au sein de Visual, même si tu exécutes du code Release, le fait de l’exécuter au sein d’un débogueur fait que ce sera beaucoup plus lent. Rien d’étonnant à ça.

Citation:

---

De base, un allocateur mémoire est « généraliste ». Il est moyen en tout. Si tu alloues beaucoup de petits objets, un allocateur personnalisé peut apporter des améliorations de performance.

Attention, cela peut se faire au détriment de la sécurité : certains allocateurs, par sécurité, nullifient la mémoire qu’ils renvoient : ce ne sera plus le cas, sauf si ton allocateur custom le fait aussi. Ça peut être ou ne pas être un problème suivant les cas (dernier exemple en date :*heartbleed…).

---

Un allocateur mémoire est « généraliste », oui, le lineaire non! Nullifier la mémoire reviendrait à ralentir l'allocation sans rien apporter.

Mais le problème ne vient pas de ma compréhension des allocateurs mais de savoir pourquoi le comportement est différent sous Visual et hors Visual en ce qui concerne les new et les delete.
Si l'on réalise ces allocations via la lanceur de Visual alors je ne serais pas étonné que Visual alloue dans une heap séparée(afin de delete les memory leak par exemple), ce qui pourrait causer ce genre de problème, mais j'aimerais juste avoir la confirmation où le pourquoi de ce comportement :)
Car il pourrait tourner plus lentement ça n'explique le bad::alloc lorsque l'on lance dans Visual Studio.

Merci :)

Bien il semblerait que ce soit tout simplement un "Out of Memory" mais que Visual Studio gère bien moins que Windows les nombreuses allocations de petites tailles. Mais Windows le gère très bien car dans le gestionnaire de tâche en lançant 8 fois le programme je n'ai aucun std::badalloc, par contre j'observe bien la mémoire physique tombé a 0 en Libre et Disponible et le cache presque à 0 également. Windows est juste à deux doit de la syncope mais aucun problème hors de l'IDE.

Je précise que j'ai ce problème même en enlevant les informations de débogages.

Enfin bref, je ne sais comment résoudre ce genre de problème sans diminué les allocations faites, ce qui ne serait pas très logique pour une phase de test dans l'IDE.

Je clos, mais n'hésitez pas si vous avez des pistes.

Merci encore white_tentacle

Citation:

---

Envoyé par Astraya

Un allocateur mémoire est « généraliste », oui, le lineaire non! Nullifier la mémoire reviendrait à ralentir l'allocation sans rien apporter.

---

Juste sur ce point, si : nullifier la mémoire apporte de la sécurité, au prix de la lenteur. En gros, cela garantit qu’un processus ne peut pas accéder à la mémoire d’un autre processus, même en allouant toute la mémoire disponible et en analysant les zones de mémoire que lui renvoient l’allocateur (en allouant beaucoup de mémoire, tu peux forcer la machine à copier dans le swap les process les moins actifs, et aller ensuite gentiment farfouiller dans la mémoire qui vient de t’être donnée, non nettoyée, pour récupérer d’éventuelles choses intéressantes).

Ok je vois le rapport. Dans mon cas, je ne cherche pas la sécurité à tout prix, je ne transporte pas de numéro de carte bleu, mais je cherche la rapidité à tout prix. Au quel cas, un calloc remplacera le malloc à l'allocation et le memset pour la destruction. C'est bon a savoir :mrgreen:

Merci