[WIN32] Pourquoi autant de mémoire ?

yo! les geeks codeurs,

J’ai écrit un machin sous Visual Studio en C/C++. Y marche bien, y va bien, le papa aussi, merci pour eux.
Toutefois je suis un peu inquiet quant au poids de la bestiole : 13 Mo en RAM. Après checking de mes allocations, je vois que je n’en fais que pour 500 Ko à grands coups de malloc et calloc. J’en conclus donc que :
 - soit je me suis planté dans mon checking d’allocs
 - soit les divers composants que j’utilise me prennent tout plein de RAM.
Pour info, mon appli joue avec les WebControls, du son, du BitBlt et du Wininet.
Question : comment “tasser” un peu tout cela ?

Thx
Antoine

Il faut bien stocker quelque part les librairies que tu utilises, pas vrai ?

Quand tu fais un malloc(), la mémoire est prise dans une heap privée gérée par le compilateur, tu as en fait plus de mémoire allouée que de réellement utilisée.

Sinon, comme il a été dit plus haut, tu utilises peut-être des contrôles qui nécessitent le chargement de dll volumineuses…

Attention, tu dis utiliser du son, mais compte-tu les buffers internes nécessaires à la librairie sonore que tu utilises ? As-tu évalué la taille MEMOIRE de ton executable (très différente de la taille sur disque, généralement à la hausse sauf si des infos de debug sont dans ton exe). Tout ça mis bout à bout peut expliquer tes 13mo. Parce que tous les services que tu utilise ont un cout mémoire, fatalement…

Ma question était parfaitement stupide (n’ayons pas peur des mots). Je devais pas être bien réveillé au moment où j’ai posté :P)
Oui, c’est tout à fait logique que je bouffe plein de RAM vu le nombres de DLL externes que j’appelle. Mon appli ne bouffe que 500 Ko mais derrière y a effectivement de quoi remplir 10 Mb. Je vais voir dans quelle mesure je peux diminuer tout ça.

Je vais refaire ma réponse en plus clair : en gros, faut que tu regardes du coté des librairies que tu utilises quelles sont les possibilités de controle de leur occupation mémoire dont tu disposes.

Accessoirement tu peux aussi essayer de compiler en optimisant pour la taille plutot que pour la vitesse, ça peut jouer sur des projets chargés en code.