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
