Discussion :

[Invité]

Bonjour,

je suis en train de réaliser des petits bouts de code et je me suis rendu compte qu'un simple programme occupe un peu trop de RAM à mon goût:

voici un exemple classique:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
#include <stdlib.h>
 
int main(void)
{
 
 system("pause");
  return 0;
}

=> occupe 1008 kilo de ram

et celui ci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#include <stdlib.h>
 
int main(void)
{
 
 while(1){
    /*nothing*/
 }   
  return 0;
}

=> occupe 672 kilo de ram

ma question: Comment cela est-il possible ? J'ai essayer avec différents flags d'optimisation etc: idem !

Quelqu'un a-t-il une idée svp ?

[loupium]

slt,

Essaye les options d'optimisation -fdata-sections et -ffunction-sections pour GCC.

[6-MarViN]

la reponse est simple : dans le premier exemple tu utilise la fonction system() qui en fait lance un shell et execute la commande transmise en parametre a ce shell. Dans le deuxieme tu fait juste une boucle infini c'est a dire une simple verification de condition.

Il est donc normal qu'un shell occupe plus de memoire qu'une verification d'expression.

[Invité]

la reponse est simple : dans le premier exemple tu utilise la fonction system() qui en fait lance un shell et execute la commande transmise en parametre a ce shell. Dans le deuxieme tu fait juste une boucle infini c'est a dire une simple verification de condition.

Il est donc normal qu'un shell occupe plus de memoire qu'une verification d'expression.

Oui mais 600kilo pour le 2eme exemple c'est quand meme bizzard ...

[Vodsky]

Essaies de ne pas inclure stdlib.h

[Invité]

Essaies de ne pas inclure stdlib.h

Idem ...

Il y a vraiment quelque chose d'étrange ....

[Obsidian]

(J'ai vu passer GCC donc je suppose que tu travailles sous Unix)

Il y a plusieurs choses qui peuvent occuper de la mémoire.

Essaie déjà « strip -s » sur ton fichier exécutable pour supprimer tous les symboles.

Ensuite, vois du côté de « ulimit -a » qui te donnera toutes les limites appliquées à un processus lors de son lancement. Notamment la taille de la pile, ce qui devrait répondre à une autre de tes questions.

[Melem]

(J'ai vu passer GCC donc je suppose que tu travailles sous Unix)

Raté, le system("pause") est une windowserie . D'ailleurs, "gcc" existe sur de nombreuses plateformes, y compris windows (MinGW, Cygwin GCC, etc.), et non pas seulement linux, même si la version linux est toujours plus complète et plus à jour que dans les autres systèmes.

PlayBoy31 : Je n'ai pas encore pu vérifier si 672 K de RAM c'est normal ou non pour une application console qui n'exécute qu'une boucle infinie, mais je pense que ça l'est. Je vérifierai ce soir. Autre chose, on ne sait pas quelles "optimisations" as-tu déjà faites. Est-ce que tu compiles déjà en release ou en debug par exemple. Quel compilateur utilises-tu.

Essaies de ne pas inclure stdlib.h

Ca c'est clair que ça ne servira à rien. L'inclusion d'un fichier d'en-tête n'entraîne pas l'inclusion des fonctions déclarées dans l'exécutable, sinon les fichiers exécutables seraient toius très volumineux ...

[Obsidian]

Raté, le system("pause") est une windowserie

Je l'ai vu aussi mais j'ai supposé qu'il s'agissait d'une habitude.

Ca c'est clair que ça ne servira à rien. L'inclusion d'un fichier d'en-tête n'entraîne pas l'inclusion des fonctions déclarées dans l'exécutable, sinon les fichiers exécutables seraient toius très volumineux ...

Pas forcément. L'inclusion de certains fichiers peut provoquer des effets de bord, notamment en définissant des directives qui sont ensuite interprétées par les bibliothèques standard ou, surtout, par le compilateur lui-même… Par exemple, des changements dans _POSIX_SOURCE, _GNU_SOURCE, etc. ou des #pragma quelconques.

[Vodsky]

J'ai fait le test, je suis sous win7 je compile avec visual studio c++ (sa devrai pas trop influer sur le résultat je pense).

J'ai tester avec la boucle inf, avec et sans le stdlib.h, je passe de 416ko a 352ko.

Remarque :j'ai pas tes 600 ko et en plus je compile en mode debug, tu est sous quel OS?

Je rajoute, voila ce qu'on peut trouver dans un .h (je précise que c'est celui de visual studio donc je sais pas si c'est une généralité ^^):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
#if !defined(_M_CEE_PURE)
/* a invalid_arg handler procedure. */
typedef void (__cdecl *_invalid_parameter_handler)(const wchar_t *, const wchar_t *, const wchar_t *, unsigned int, uintptr_t); 
 
/* establishes a invalid_arg handler for the process */
_CRTIMP _invalid_parameter_handler __cdecl _set_invalid_parameter_handler(_In_opt_ _invalid_parameter_handler _Handler);
_CRTIMP _invalid_parameter_handler __cdecl _get_invalid_parameter_handler(void);
#endif

ça ressemble a un truc qui est sensé s’exécuter non? c'est étrange tout de même.

[Melem]

L'inclusion de certains fichiers peut provoquer des effets de bord, notamment en définissant des directives qui sont ensuite interprétées par les bibliothèques standard ou, surtout, par le compilateur lui-même… Par exemple, des changements dans _POSIX_SOURCE, _GNU_SOURCE, etc. ou des #pragma quelconques.

Ah oui je n'y ai pas pensé. Sur le moment, je ne voyais que les déclarations de fonctions en fait.

Vodsky :

- #if !defined(_M_CEE_PURE) ... #endif sert à inclure la portion de code entourée si et seulement si la macro _M_CEE_PURE est définie.

- typedef void (__cdecl *_invalid_parameter_handler)(const wchar_t *, const wchar_t *, const wchar_t *, unsigned int, uintptr_t); définit le type _invalid_parameter_handler, qui est alors un pointeur de fonction.

- Enfin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
_CRTIMP _invalid_parameter_handler __cdecl _set_invalid_parameter_handler(_In_opt_ _invalid_parameter_handler _Handler);
_CRTIMP _invalid_parameter_handler __cdecl _get_invalid_parameter_handler(void);

Ces deux lignes sont des déclarations de fonction.
- _CRTIMP est un define de __declspec(dllimport). Il permet d'indiquer au compilateur que le corps de la fonction se trouve dans une DLL.
- __cdecl est la convention d'appel utilisée
- _In_opt_ est une macro vallant vide et sert juste à indiquer que le paramètre qui suit est un paramètre d'entrée ("in" parameter), ce qui signifie que la fonction ne modifie pas "l'objet pointé" malgré l'abscence du mot-clé const et qu'il est optionnel, ce qui signifie que passer NULL a un sens pour le fonction.

En gros, ce ne sont que des déclarations, et pas une seule instruction.

[Vodsky]

Je suis toujours ravi d'apprendre!

Merci