Utilisation de la mémoire

J'ai une petite question . . .

Pourquoi est-ce qu'un code simple comme ça :

Code:

---

1 2 3 4 5 6 7

# include <stdio.h>   int main() { getchar(); return 0; }

---

Utilise 328k de mémoire d'après le gestionnaire des tâches de windows? . . .

328k c'est pas beaucoup pour un programme qui ne fait rien! . . .?

Merci beaucoup!

Alex

un programme qui ne fait "rien" doit quand même inclure le minimum pour

1. être activable par l'OS (lorsqu'on tape run)
2. construire un environnement C "standard"
3. enfin appeler la routine "main"

Sur linux, la commande pmap permet de lister le contenu de l'espace virtuel d'un process... Malheureusement, je ne connais pas l'équivalent Windows.
- W

Merci beaucoup!

Il y a moyen de "voir" ce contenu??

Il y a toujours moyen... modulo outils et droits d'accès.
Le plus simple est d'utiliser un "debuger" genre "gdb".
- W

Citation:

---

Envoyé par Alexandreg12

Pourquoi est-ce qu'un code simple comme ça :

Code:

---

1 2 3 4 5 6

# include <stdio.h> int main() { getchar(); return 0; }

---

Utilise 328k de mémoire d'après le gestionnaire des tâches de windows? . . .

328k c'est pas beaucoup pour un programme qui ne fait rien! . . .?

---

Bah, ça dépend de plein de choses.

- La machine
- Le système
- Le compilateur et sa config (debug/release)
- la granularité de la bibliothèque

(chez moi, 184 k en mode debug : Vista SP1, MinGW)

bref, il ne faut pas trop s'étonner que ça prenne de la place sur un PC moderne. On peut espérer de meilleurs performances avec un logiciel conçu pour être embarqué.

Citation:

---

Envoyé par Alexandreg12

J'ai une petite question . . .

Pourquoi est-ce qu'un code simple comme ça :

Code:

---

1 2 3 4 5 6 7

# include <stdio.h>   int main() { getchar(); return 0; }

---

Utilise 328k de mémoire d'après le gestionnaire des tâches de windows? . . .

328k c'est pas beaucoup pour un programme qui ne fait rien! . . .?

Merci beaucoup!

Alex

---

Il faut voir ce que le gestionnaire reporte exactement, il y a sûrement de la mémoire que l'OS utilise en interne ou qui est partagée avec d'autres processus.

Citation:

---

Envoyé par Alexandreg12

Pourquoi est-ce qu'un code simple comme ça [...] Utilise 328k de mémoire d'après le gestionnaire des tâches de windows?

---

C'est une excellente question, que peu de gens se posent encore aujourd'hui.

C'est dû a beaucoup de choses, mais la première peut être le fait que ton programme est compilé en mode debug. Dans ce cas, ton exécutable contient presque la totalité du code source plus quelques autres infos pour que le debugger puisse te dire exactement où te trouves. Une fois le programme au point, toutes ces informations sont abandonnées.

Cependant, ça ne suffit pas. Comme on l'a dit, le nombre d'interdépendances augmente à chaque génération de l'OS et élargit toujours plus la taille de l'overhead d'un programme. Dans certains cas, cela peut-être délibéré : si on a de la place, on peut s'en servir pour faire directement des optimisations. Par exemple, insérer deux kilo-octets de zéros au milieu d'un fichier pour que la prochaine page soit correctement alignée :-) Ça a l'air d'être une hérésie, comme çà, mais si ça ne dépasse pas la taille du cluster alloué sur ton disque par ton fichier, tu n'y perds rien.

N'empêche que c'est toujours très drôle de scanner un fichier .exe et de comparer le pourcentage de zéros dans son contenu par rapport aux 255 autres valeurs qu'un octet peut prendre :-)

Avec la mémoire virtuelle, est apparu un nouveau phénomène : un fichier qui prend de la place sur le disque n'en prend pas forcément en mémoire résidente puisque les parties réellement utiles ne seront mappées en mémoire que lorsqu'on essaiera effectivement d'y accéder (mêmes mécanismes que le swap, appliqués aux fichiers normaux). À ce stade, la répartition des données peut avoir de l'importance, tandis que la place occupée ne le sera réellement que sur le disque, dont la capacité croît avec les évolutions technologiques beaucoup plus rapidement que la mémoire vive.

Pour autant, il y a quelques années (un peu plus d'une dizaine, tout de même), je m'étais demandé quelle était la taille du plus petit exécutable possible sous DOS/Windows. J'avais fini par faire un .COM de 2 octets contenant CD 20 (Int 20h : fonction de sortie historique sous DOS). Je m'étais quand même fait battre : quelqu'un m'avait fait remarquer que le standard imposait à un programme COM d'avoir une pile débutant par 00 00. Un RET (sur 16 bits, donc) nous ramenerait alors en début de segment, c'est à dire en plein sur le PSP ! ... lequel débutait toujours, par convention, par les codes CD 20 ! C'était bien fichu, mine de rien.