On Tue, Nov 09, 2004 at 12:45:20PM +0100, Laurent Martelli wrote: > >>>>> "Laurent" == Laurent Martelli <[EMAIL PROTECTED]> writes: > > >>>>> "Gabriel" == Gabriel Paubert <[EMAIL PROTECTED]> writes: > > [...] > > Gabriel> Non, ce n'est pas du debug, en tout cas pas uniquement. > > Laurent> En tout cas, ce n'est pas propre au C++, je viens de > Laurent> constater avec un certain effarement qu'une pauvre fonction > Laurent> C d'une seule ligne peut générer un .o de 260Ko!!! > Laurent> Heureusement, quand je strippe ça redescends à 600 octets > Laurent> :-) > > Laurent> Et je m'aperçois que si je remplace un #include <gtk/gtk.h> > Laurent> par quelque chose d'un peu plus spécifique, ça tombe à 80K > Laurent> non strippé. > > Autre optimisation intéressante: utiliser -gstabs au lieu de -g. Ca > m'a permis de passer de 13Mo à 2,5Mo pour un .so. Au tout départ mon > .so faisait 27Mo!!!
Les options de debug prennent de la place dans les .o, mais c'est normal et ce n'est pas ça qui me gêne, puisque je ne compile quasiment jamais avec -g et n'utilise que très rarement gdb. Tout d'abord, il s'agit de sections qui ne seront chargées en mémoire que par le débogueur. Et elles sont bien séparées dans l'exécutable. Par contre, quand, par exemple, je dérive un Gtk::RadioButton en C++ pour pallier les défauts dudit objet (tu peux le changer de groupe comme tu veux, ce dont je n'ai jamais eu besoin, mais il faut rajouter du code pour l'utilisation la plus simple: simplement mettre à jour une variable reflétant la sélection et signaler que la variable a changé de valeur, ce qui est ce dont j'ai besoin dans 99% des cas). En gros la fonction que je remplace (on_toggled) fait dans les 15 instructions machine, mais ça prend 20ko d'embonpoint éparpillés sur 6 pages (de 4k, 3 de code, 3 de données) qui seront toutes ou presque chargées parce qu'à l'éxécution on en aura besoin, mais de façon très partielle. Enfin, du moins pour certains widgets Gtkmm, la philosophie est: «pourquoi simplifier la vie des développeurs quand on peut la leur rendre impossible». > > Apparement, le format de debuggage DWARF2 (utilisé par défaut avec -g) > est en théorie plus compact que stabs mais le linker n'est pas encore > capable d'éliminer la duplication d'infos avec DWARF2 mais le fait > avec stabs. Et stabs ne mets suffisement d'infos pour débugger du C++ > correctement. > > Pour plus d'infos: http://gcc.gnu.org/ml/gcc/2003-02/msg01995.html C'est vrai, mais ça ne fait pas partie de mes problèmes, qui sont: - génération de dizaines de kilo-octes de code et de données jamais utilisées mais qui vont être chargés à cause de leur éparpillement sur des pages utilisées très partiellement. C'est la cause d'une augmentation considérable de la mémoire utilisée à l'exécution et ma machine avec 768Mb et en gros un Konsole (plusieurs sous-fenêtres) et mozilla et déjà en train de swapper. C'est ridicule. - lenteur de g++, je compile mon C sur un vieux PPC 233MHz et le C++ sur un PIV 2.8 GHz, ça va _beaucoup_ plus vite en lignes/secondes dans le premier cas (même en tenant compte des include). C'était le point de départ de ce thread, je ne me vois pas compiler du C++ sur un PII 266, en tout cas pas une application qui ait tendance à utiliser pas mal de génériques (template). - messages d'erreur complètement (abs)cons et déroutants de g++ sur des choses aussi simples qu'une parenthèse oubliée avant un point virgule et autres bêtises d'édition aussi triviales. Gabriel
