Re: HS: C++

[Gabriel Paubert <paubert@iram.es>]

On Tue, Nov 09, 2004 at 12:45:20PM +0100, Laurent Martelli wrote:
> >>>>> "Laurent" == Laurent Martelli <laurent@aopsys.com> writes:
> 
> >>>>> "Gabriel" == Gabriel Paubert <paubert@iram.es> 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