Des définitions de fonction/méthode supplémentaires augmentent-elles l'empreinte mémoire d'un programme?

Question

En C++, la définition de méthodes ou de fonctions supplémentaires qui ne sont pas utilisées entraîne-t-elle une empreinte mémoire plus importante ou une vitesse d'exécution plus lente?

Fondamentalement, j'ai plusieurs méthodes de débogage d'utilitaire dans une classe, dont aucune n'est requise pour l'utilisation normale de la classe. Cela ferait-il une différence en termes d'empreinte mémoire ou de vitesse, que ces définitions restent ou non si elles ne sont jamais utilisées? Par exemple:

class myClass 
{ 
    public: 

     //Something the user of this class would use 
     int doSomething() {...} 

     //Something used solely to make sure I wrote the class properly 
     bool isClassValid() {...} 
}; 

... 

myClass classInstance(); 
myClass.doSomething(); 

Answer 1

Ne gardez pas toujours tout le code dans la mémoire. Comme le code est constant, le système d'exploitation peut toujours le charger à partir d'un fichier à la demande, comme s'il chargeait des données dynamiques à partir de swap. Mais cela ne signifie pas que le code inutilisé n'est jamais chargé car le système d'exploitation ne le charge pas par des méthodes séparées mais par des pages. En d'autres termes, il est très difficile de prédire quelles parties de votre segment de code finiront dans la mémoire à moins d'avoir une connaissance approfondie de votre système d'exploitation et de la structure de votre segment de code. La seule chose qui peut être dite à coup sûr est qu'il est parfaitement possible que votre code consomme moins de mémoire physique que sa taille réelle. En ce qui concerne la vitesse d'exécution, la réponse est non je pense. Cela peut augmenter la vitesse de chargement de l'application, mais lorsque le code est exécuté, personne ne se soucie de sa taille et cela n'a absolument aucun effet sur la vitesse. C'est-à-dire, à moins que vous soyez proche de votre limite de mémoire et que le système d'exploitation commence à changer beaucoup et que tout devient très lent.

Comme les autres l'ont déjà mentionné, le compilateur peut optimiser votre code. Mais c'est aussi quelque chose que vous pouvez faire vous-même en utilisant #ifdefs pour vos méthodes de débogage et il est généralement recommandé de le faire.

Answer 2

Vos méthodes génèrent du code. Ce code va exister quelque part. Lorsque votre exécutable est construit, il existera probablement dans votre exécutable. Cela augmentera la taille de l'exécutable, augmentera son temps de chargement et peut affecter son comportement de cache. Donc, la réponse est oui". Sauf: ... Il devient plus boueux.

Un bon compilateur et un bon éditeur de liens peuvent interagir de sorte que tout code que vous n'utilisez pas réellement ne soit pas intégré dans votre exécutable. La granularité de ceci varie mais peut aller jusqu'à des fonctions individuelles (et peut-être même plus bas dans certaines langues). Si le compilateur peut signaler que la méthode en question n'est jamais réellement appelée et que l'éditeur de liens est assez intelligent pour amener le code au niveau de la fonction, alors la réponse devient "non". Donc, en bref, la réponse est "oui" ou "non" en fonction d'une foule de facteurs que vous aurez à rechercher liés aux outils que vous utilisez et à la plate-forme sur laquelle vous travaillez.

Answer 3

Les méthodes inutilisées sont généralement présentes dans l'exécutable sauf si vous dites à l'éditeur de liens de les rechercher et de les supprimer. Par exemple, sur Mac, vous pouvez passer -dead_strip à ld pour supprimer un tel code mort. Si vous utilisez Windows Visual C++, vous pouvez passer /OPT:REF à link.exe (j'imagine que Visual Studio définit automatiquement votre projet pour passer cette option dans les versions de version, mais pas dans les versions de débogage.)

Answer 4

Déterminer si le code est inutilisé ou non est un problème assez difficile. Il suffit d'écrire un programme Hello world, un lien statique avec glibc, et d'utiliser objdump pour voir toutes les ordures qui se retrouvent dans votre fichier binaire. La grande majorité de ce code n'est pas utilisé, mais il est référencé de manière à rendre difficile ou impossible pour un compilateur ou un éditeur de liens de l'optimiser.Sauf si vous êtes un auteur de bibliothèque vous travaillez très diligemment pour éviter d'introduire ce genre de dépendance, les fonctions/méthodes inutilisées vont probablement gaspiller de l'espace, et probablement beaucoup. Je soupçonne que c'est encore plus difficile en C++ qu'en C.