C’est normal 
Le Task Manager t’indique la memoire allouee pour le process, qu’elle soit partagee par d’autres apps, c’est pas indique dans le total. De meme de la memoire poru etre « pre-allouee » alors qu’elle l’est pas vraiment, et apparait donc comme prise alors qu’en fait elle est disponible. De la meme maniere si tu appellait « SetWorkingSet » ou autre chose du genre, l’OS peut pager sur disque des pages qui sont en fait necessaires et tu te retrouves avec un « total memory » tout aussi faux, mais dnas l’autre sens. C’est loin d’etre simple a partir du moment ou tu utilises un framework partage complexe, et plus le framework est complexe, plus les chiffres donnees veulent pas dire grand chose comme ca sans vraiment comprendre ce qui se passe. Aussi une app ou un framework optimise fera beaucoup d’allocation si elle en a la possibilitee le plus tot possible, du pre-fetching, du caching, etc. La memoire est la pour etre consommee, a quoi bon payer pour plein de ram si c’est pour en avoir 80% de libres, un bon prog va en utiliser autant qu’il peut. L’important c’est que chaque app le fasse tout en restant gentil avec ses voisins si eux aussi en ont besoin. Idealement tu tourneras a peu de megs de dispo en permanence. C’est ce que tu veux, c’est la situation optimale. Qui a dit que ca devait etre aussi simple que de taper top et de matter un chiffre par ligne :P?
Quand tu fais du profiling, comme ca, il faut pas utiliser le task manager, il te faut plutot utiliser les perfs counter (sous win) et regarder la taille de « Private Byte », ca c’est surement un peu plus proche de la « veritable » memoire allouee par ton app qui n’est pas partageable avec d’autres applications au cas ou elle charge la meme DLL (du moment que la dll a pas ete rebasee…). Si tu veux des trucs plus precis ca se fait au debugger avec des trucs du genre !dumstack -stat ou autre sous windbg, et encore ca t’expliquera pas le fonctionnement interne de l’app si t’as pas le code a moins d’y passer des siecle, parcequ’elle peut ajuster son fonctionnement interne en fonction de la « memory pressure » (j’ai plein de place? je rajoute un cache pour aller plus vite, la place s’en va? bon tant pis j’enleve mon cache, je voudrais pas gener…). Sinon sous un unix ca s’appelle « Resident Private Memory Usage » qui est sous RPRVT dans « top » je crois, RSHRD etant le shared… T’as des outils du cote de systernals (le tres bon site web) qui peuvent te servir aussi sous windows.
Au final, plus ton framework fait de chose, ici QT, plus un programme debile genre hello world aura un overhead important, et plus il sera aussi difficile d’obtenir un simple chiffre qui te donne une idee de ce qui se passe. C’est parfaitement normal. Si ton prog fait rien il y a aucune utilite a charger tout le framework, mais c’est pas comme ca que marchent les libs, tu charges toute une lib ou rien, pas juste un bout de lib. Et c’est pas interessant de tout decouper en petits bouts pour plein d’autre raisons. Y a pas vraiment de bizzarerie, la gestion de la memoire est devenue bien plus complexe que « prog X prend Y megs » sur un OS moderne, ca donne une image faussee de la realite de voir ca comme ca et tout comprendre par process requiert un debugger, pas juste top ou le task manager La plupart du temps a moins d’avoir une fuite, ou de vraiment voir des chiffres dingues, vaut mieux laisser le systeme gerer tout ca et pas s’inquieter pour ce qui apparait comme 6 miserables megs (c’est minuscule!)
« How I learned to stop worrying and love memory usage » B)