Je n'ai pas encore lu l'article car le site est très lent à répondre.
De plus en plus, la mémoire occupée par les programmes me semble démente. Mon navigateur montre rapidement à plus d'une centaine de Mo (d'après le gestionnaire des taches de windows), et même si la mesure de la mémoire occupée est sujet à diverses interprétation (comment compter les fichiers mappés qui sont en lecture seule, les librairies partagées entre différentes applications, les pages qui ne sont jamais utilisées) je pense qu'il y a des efforts à faire.
Par contre, je suis très critique vis à vis des solutions citées:
Pour le strip, pas de contestation.
La compilation statique peut donner l'impression que le binaire est plus petit, mais on perd un gros intérêt des librairies dynamiques, qui est qu'il n'est plus nécessaire de les dupliquer en mémoire. Et puis le statique qui présente un intérêt pour un programme Hello World qui se contente d'appeler printf et exit est probablement un lourd handicape pour une application qui fait un peu plus de choses et qui va appeler bien plus de fonctions dans bien plus de librairies.
Supprimer les parties ELF du binaire qui ne sont pas indispensable permet de faire gagner quelques octets, quelques Ko même peut-être, mais on se contente de gagner un peu de place sur le disque, cela ne change rien à la mémoire, et sur plusieurs dizaines ou quelques centaines de Mo, c'est complètement négligeable.
Enfin l'optimisation en assembleur est à mon avis une régression au niveau des années 80. J'utilise à mi-temps un PPC, et évidement, l'assembleur concerne rarement cette architecture, une optimisation en assembleur pousse l'assertion Ordinateur = compatible IBM-PC qui masque une grande partie de la richesse de l'informatique, surtout libre.
Optimiser une routine en assembleur peut se comprendre dans des situations où le temps est critique, pour utiliser des instructions mal supportées par le compilateur, elles ont leur place dans les librairies de codage/décodage audio et vidéo, et dans ce cas, il existe des alternatives portable pour les autres architectures; mais aucune écriture en assembleur ne va permettre de gagner une quantité significative de mémoire lors de l'exécution, le gain de quelques octets ne justifie pas la lourdeur , les problèmes de portabilité et de maintenance de l'assembleur, le C est suffisement souple de ce coté.
# Intéressant mais...
Posté par Sébastien Koechlin . En réponse au journal Compilation et optimisation de l'empreinte mémoire. Évalué à 1.
De plus en plus, la mémoire occupée par les programmes me semble démente. Mon navigateur montre rapidement à plus d'une centaine de Mo (d'après le gestionnaire des taches de windows), et même si la mesure de la mémoire occupée est sujet à diverses interprétation (comment compter les fichiers mappés qui sont en lecture seule, les librairies partagées entre différentes applications, les pages qui ne sont jamais utilisées) je pense qu'il y a des efforts à faire.
Par contre, je suis très critique vis à vis des solutions citées:
Pour le strip, pas de contestation.
La compilation statique peut donner l'impression que le binaire est plus petit, mais on perd un gros intérêt des librairies dynamiques, qui est qu'il n'est plus nécessaire de les dupliquer en mémoire. Et puis le statique qui présente un intérêt pour un programme Hello World qui se contente d'appeler printf et exit est probablement un lourd handicape pour une application qui fait un peu plus de choses et qui va appeler bien plus de fonctions dans bien plus de librairies.
Supprimer les parties ELF du binaire qui ne sont pas indispensable permet de faire gagner quelques octets, quelques Ko même peut-être, mais on se contente de gagner un peu de place sur le disque, cela ne change rien à la mémoire, et sur plusieurs dizaines ou quelques centaines de Mo, c'est complètement négligeable.
Enfin l'optimisation en assembleur est à mon avis une régression au niveau des années 80. J'utilise à mi-temps un PPC, et évidement, l'assembleur concerne rarement cette architecture, une optimisation en assembleur pousse l'assertion Ordinateur = compatible IBM-PC qui masque une grande partie de la richesse de l'informatique, surtout libre.
Optimiser une routine en assembleur peut se comprendre dans des situations où le temps est critique, pour utiliser des instructions mal supportées par le compilateur, elles ont leur place dans les librairies de codage/décodage audio et vidéo, et dans ce cas, il existe des alternatives portable pour les autres architectures; mais aucune écriture en assembleur ne va permettre de gagner une quantité significative de mémoire lors de l'exécution, le gain de quelques octets ne justifie pas la lourdeur , les problèmes de portabilité et de maintenance de l'assembleur, le C est suffisement souple de ce coté.