On 14/12/2010 16:33, Audrius Šaikūnas wrote:

Hello,

I've noticed that libraries that are compiled even with -dynamic are really huge: libHScairo-0.12.0-ghc6.12.1.so - 1.4 M libHSgio-0.12.0-ghc6.12.1.so - 1.6 M libHSgtk-0.12.0-ghc6.12.1.so - 14 M

(ldd confirms that these libraries are really linked dynamically with the rest of the world)

just to name a few. All of them are striped with "strip -s". At this point *bindings* to C libraries are larger that the libraries themselves, which I find unacceptable.

So I decided to dig a bit deeper and when examining cairo-0.12.0 I found that Types.o object file consumes 1.5 MB. So I "cleaned" up Types.hs and tried to compile it separately from the rest of the library:

% ghc -c Types.hs&& ls -lh | grep Types.o -rw-r--r-- 1 angel angel 69K 2010-12-14 18:24 Types.o % rm Types.o % ghc -c Types.hs -O&& ls -lh | grep Types.o -rw-r--r-- 1 angel angel 1.1M 2010-12-14 18:25 Types.o

So adding -O when compiling Types.hs makes the size of object file jump from 69K to 1.1M. Just think about it - the file contains *two* *enums* and nothing more. And yet it twice as large as a full-blown application like gedit.

So I would like to ask you whether such behavior is known and should such this be considered as a bug?

This particular example seems to be fixed, at least with the current HEAD: $ ghc -O -c en.hs $ ll en.o -rw-rw-r-- 1 simonmar GHC 84248 2010-12-14 16:47 en.o $ size en.o text data bss dec hex filename 23210 3680 0 26890 690a en.o But if you do find a case of code bloat, by all means file a bug and we'll look into it. Cheers, Simon