Non mais oh !
350 Mo de mémoire consommée pour seulement le gestionnaire de bureau !
Mais je rêve !!!!
PpHd (./3) :
Je sens que le prochain preos verra une légère inflation sur sa taille
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1348 pphd 20 0 1920772 428824 85292 S 0,0 2,6 2:25.55 gnome-shell
Zerosquare (./18) :
En général, quand tu te préoccupes de la mémoire occupée, tu n'alloues pas non plus des pelletées en te disant "pas grave, je vais pas écrire dedans", mais bon ^^
spectras (./19) :
Tu noteras d'ailleurs que le graphe que tu as mis est complètement faussé, car il ignore purement et simplement les optimisations de mémoire des environnements. Par exemple, KDE à vide prend beaucoup de place, car il précharge toutes les libraries. L'intérêt, c'est que quand tu lances une application KDE il forke le launcher, ce qui permet de bénéficer à fond du copy-on-write : en plus des pages de code, l'essentiel des pages de données et une bonne partie de la pile sont communes également.
J'ignore si gnome-shell fait la même chose, mais ça serait très possible. C'est un gain important en consommation mémoire et en temps (le linkage dynamique est en grande partie fait). Mais ça a pour effet que les outils type ps / top imputent la mémoire au shell au lieu des applications.
Au lieu de te tapper un shell à 30Mo + 10 applications à 50Mo (soit un total de 530), par exemple, tu auras un shell à 50 + 10 applications à 40Mo (soit un total de 450).
C'est un peu schématisé mais c'est l'idée. Oh et comme effet secondaire, ça fait râler les utilisateurs qui ne voient que "50Mo c'est plus gros que 30Mo", et ne font pas le rapprochement avec le gain sur les autres applications.
D'autant plus que le gain n'est pas évident car elles "consomment" toujours autant, c'est simplement que la quantité en "shared" est plus grande.
PpHd (./21) :
Je n'ai compté que la mémoire RES, et pas la mémoire partagé entre process ! (Je n'ai pas essayé avec KDE).