Salut à tous !
Actuellement en stage en entreprise, on m'a filé un programme C et on m'a demandé de réduire la mémoire utilisée par ce dernier, qui est actuellement de 98%.
Bon j'adore le C, mais n'étant qu'en 2°A de DUT GEII, je n'ai pas ces compétences. Je suis donc parti à la recherche d'infos sur internet, mais ça prend du temps donc je viens ici pour avoir un complément, en espérant que vous puissiez m'aider !
Merci de votre aide !
Bonjour
Euh .... 98% de quoi ??Envoyé par RedArrrow
Il faudrait voir ce qui consomme et s'assurer déjà que cette consommation est anormale.Bon j'adore le C, mais n'étant qu'en 2°A de DUT GEII, je n'ai pas ces compétences. Je suis donc parti à la recherche d'infos sur internet, mais ça prend du temps donc je viens ici pour avoir un complément, en espérant que vous puissiez m'aider !
Peut être des désallocations non effectuées ?
Le programme "prend" 98% de la ROM, et faut que je réduise cela.Euh .... 98% de quoi ??
Qu'entends-tu par désallocations non effectuées ?Il faudrait voir ce qui consomme et s'assurer déjà que cette consommation est anormale.
Peut être des désallocations non effectuées ?
De la ROM ? Donc c'est un programme embarqué sur une carte et ce n'est pas la mémoire que consomme le programme mais la taille du code alors.
Ce n'est plus la question puisque contrairement à ce que tu disais ce n'est pas la consommation mémoire du programme mais sa taille qui est en cause.Qu'entends-tu par désallocations non effectuées ?
Bref un peu plus de précisions serait plus que nécessaire car deux messages, deux infos contradictoires, ça va être dur de t'aider.
Oui pardon c'était clair pour moi mais en fait ça ne l'est pas tant que ça.
Oui oui je parle bien d'un programme qui est transféré sur un PIC.
Pour faire plus clair : quand je compile mon code, une fenêtre s'ouvre avec tout le blabla habituel sur les erreurs, etc .. et à la fin il y a écrit : Memory usage : 98%.
Ils m'ont demandé de réduire ce chiffre.
Bonjour,
Malgré vos explications, je ne vois pas de quoi vous parlez.
Memory usage : 98 % .... mais de quoi ?
@+
Not only is it not right, it's not even wrong!
bonjour
Quand on programme "proprement", on vide ou détruit les variables devenues inutiles. Le gain de RAM (et non de ROM) est souvent appréciable !
On parle de la ROM, le "disque dur" de mon micro.Memory usage : 98 % .... mais de quoi ?
Merci pour ta réponse, mais du coup dans mon cas ce n'est pas ce que je recherche.Quand on programme "proprement", on vide ou détruit les variables devenues inutiles. Le gain de RAM (et non de ROM) est souvent appréciable !
Oui, mais comme son problème vient de la taille du code (et pas du tout de la conso mémoire du programme) ma remarque était devenue sans objet.
De toute manière il faut réduire la taille du code et/ou celle des allocations statiques.
Sans plus d'info je ne vois pas ce qu'on peut dire de plus.
Ok pour le premier, mais concernant celle des allocations statiques, on fait ça comment ?réduire la taille du code et/ou celle des allocations statiques.
Tu as besoin de quoi d'autre comme infos ?Sans plus d'info je ne vois pas ce qu'on peut dire de plus.
Les remplacer par des allocations dynamiques par exemple.
Et vérifier leur pertinence.
Ok merci je vais aller voir comment on fait ces allocations dynamiques.
Si d'autres personnes ont une piste, je suis ouvert à toute proposition !
Ok, fallait décoder la question initiale (comme trop souvent hélas) !
On peut toujours optimiser le code pour réduire sa taille mais on ne gagne généralement que quelques pouillèmes. Je doute que son problème vienne de là, à moins que ce soit un tout petit disque ou un programme gigantesque ? Dans les deux cas, la solution est ailleurs.
C'est une petite mémoire de PIC, le programme (dont je n'ai pas accès à l'exe) prend 98% de cette mémoire, et ma tâche est de réduire la place du programme.
On m'a parlé de padding, et d'allocations dynamiques afin de gagner en espace.
Bonjour,
Si c'est le code qui prend de la place alors il faut le repenser, les solutions préconisées sont inopérantes.
D'abord faire la chasse au processus redondants :
exemple plusieurs process calculent les mêmes données à partir des mêmes variables (c'est très commun avec le saucissonnage), on crée alors un process qui fait le calcul pour tous les autres en utilisant des variables globales, si cela ne suffit pas passage en assembleur (là c'est pour les pro).
En règle générale optimisation et modularité ne naviguent pas dans le même bateau.
JR
l'électronique c'est pas du vaudou!
Merci pour ta réponse !
On m'a aussi parlé de padding, aussi inopérant que les allocations dynamiques ?
Ok pour process unique avec variables globales !
Qu'entends-tu par modularité ?
Le padding c'est insérer des octets à doite à gauche, c'est donc un peu fourre tout pour traduire précisément, mais dans le contexte d'économie mémoire, je vérifierai le padding utilisé par le compilateur: les "objets" alloués statiquement ont des adresses alignées sur des entiers, et c'est également vrai pour les champs des structures.On m'a aussi parlé de padding, aussi inopérant que les allocations dynamiques ?
L'allocation dynamique est utile si tu as du rab en RAM, tu pourrais ainsi transférer des données de la ROM vers la RAM, de plus elle te permet de libérer la mémoire lorsqu'elle n'est plus nécessaire, ce qui n'est pas possible avec l'allocation statique (du moins je ne crois pas).
Il est difficile d'établir un diagnostique sans accéder au code...
Merci pour ta réponse lou_ibmix_xi !
Concernant le padding, je ne connais pas les options utilisées par mon compilateur.
Concernant les allocations dynamiques, le programme utilise, au plus, 42% de la RAM, donc stockées des données "temporaires" sur cette dernière me parait être une solution plutôt intéressante.
J'ai trouvé quelques pistes de mon côté !
En ouvrant par curiosité les fichiers du dossier de mon projet, je suis tombé sur plusieurs fichiers intéressant.
Tout d'abord un fichier nommémain.LST: il y a écrit en en-tête "ROM used : 15106 bytes (92%), Largest free fragment is 1274". Le 1274 signifie qu'il y a un "trou" de 1274 bits en plein milieu ?? (donc possibilité de gagner de la place je présume)
Ensuite, j'ai ouvert le fichier main.sta : je vous montre pour une meilleure compréhension : #####################
Lien vers serveur externe supprimé
Merci de respecter les consignes de ce forum:http://forums.futura-sciences.com/pr...ges-forum.html .
Ici on voit clairement que le main.c occupe 54% de la ROM, MATH.H 9%, stdlib.h 14% et string.h 4%. Déjà la somme ne fait que 81%, donc on a 11% qui disparaisse je ne sais où. Première idée que j'ai, tout simplement commenter les fonctions non utilisées des bibliothèques math, stdlib et string. Je pense qu'il y a moyen de gagner 4-5%. Si vous reprenez l'image juste au-dessus, il y a un tableau avec les colonnes Page, ROM, %, RAM et Functions. Quelqu'un saurait m'expliquer comment le déchiffrer, car je ne sais pas de quel pourcentage on parle.
Finalement j'ai ouvert le fichier main.tre : pour une meilleure comppréhension : ###################### . J'ai un doute quand à son rôle, j'ai l'impression qu'on a ici l'utilisation de la RAM par chaque fonction (ce qui m'intéresse pour la suite), mais si l'on prend l'exemple de la fonction Read_EEPROM, je ne saisis pas la signification du 0/152. J'imagine que le Ram=9 veut dire 9 octets stockés sur la RAM ?
L'idée sur laquelle je pars du coup c'est essayer de gagner de la place sur les fonctions non utilisées des librairies, et ensuite tester la mémoire occupée par chaque fonction du main, et tester des modifications pour voir si je peux en gagner un peu plus.
J'attends vos réponses pour savoir si c'est viable comme solution, merci !
Dernière modification par Jack ; 30/04/2015 à 10h37.
Main_sta.JPG
Photo correspondant au main.sta
Main_tre.JPG
Photo correspondant au main.tre
Si tu ne fais que les "commenter" ça ne va pas réduire la taille des fichiers .h
mais je ne comprends pas bien: est-ce la taille du code que tu veux réduire, de l'exécutable, du programme chargé en mémoire?
Les déclarations dans un fichier .h n'ont pas la moindre influence sur la taille d'un programme.
C'est juste un check de paramètre pour le compilateur, pouvant être couplé éventuellement avec des meta-instructions de compil concernant la convention d'appel.
Dernière modification par Bluedeep ; 30/04/2015 à 14h05.
Merci minushabens et Bluedeep pour vos réponses !
Alors effectivement, après avoir commenter puis supprimer les fonctions des bibliothèques non utilisées je me suis aperçu qu'effectivement je ne gagne pas en memory usage. Le seul endroit où j'ai eu une amélioration c'est sur la RAM lorsqu'elle fait un "pic d'utilisation", c'est-à-dire que je suis passé de 18%-42% à 18%-41%, ce qui est ridiculement insignifiant !
Ce que je veux c'est que le programme prenne moins de place sur la ROM de mon PIC, donc d'après ce que m'ont dit d'autres forumeurs ça revient à réduire le code, ou l'optimiser tout du moins.
Normalement, il doit y avoir moyen de paramétrer le compilateur de manière à optimiser la vitesse d'exécution ou la taille du code notamment. Je ne connais pas ton compilateur, mais tu dois bien avoir sa doc.
Solution trouvée !
Tout simplement en lisant la datasheet du compilateur, j'ai trouvée une option, #OPT n
avec n allant de 1 à 11 et qui permet de choisir le niveau d'optimisation du code !
J'ai pu donc passer de 92% à 71% !
Merci à tous !
