object code blow up by minor source code change

[c_maeder]

If you unpack the archive and compile the files with
optimization by: 

 time ghc -no-recomp --make -O HasCASL/hacapa.hs

This takes about 5 minutes and generates an unstripped
binary of 4MB.

Apply the (little) patch for HugesPJ.hs -- the one I've
sent before and that is included as "patch" in the
top-level directory. Our (slightly modified) copy of
HughesPJ.hs is Common/Lib/Pretty.hs:

 patch -p0 Common/Lib/Pretty.hs patch

Now compilation takes 7 minutes and the binary gets
size 6 MB. Particularly the file HasCASL/PrintLe.o has
grown from 90 KB to 2 MB. (Compiling HasCASL/PrintLe.hs
takes visibly longer, too)

(Patching can be reversed by:
 patch -p0 -R Common/Lib/Pretty.hs patch
)

This blow-up of object code caused a link failure on
our mac for a final (stripped) binary that should have
a size of around 36 MB.

(The link failure on macs is another issue that may
need attention in the future.)

The data below is obtained with ghc-6.4.1 under linux.

Cheers Christian

maeder@turing:~/haskell/examples> uname -a
Linux turing 2.6.11.4-21.9-default #1 Fri Aug 19
11:58:59 UTC 2005 i686 i686 i386 GNU/Linux
maeder@turing:~/haskell/examples> ghc --version
The Glorious Glasgow Haskell Compilation System,
version 6.4.1
maeder@turing:~/haskell/examples> gcc --version
gcc (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
Copyright (C) 2003 Free Software Foundation, Inc.
[...]
maeder@turing:~/haskell/examples> time ghc -no-recomp
--make -O HasCASL/hacapa.hs
Chasing modules from: HasCASL/hacapa.hs
Compiling Common.Lib.State ( ./Common/Lib/State.hs,
./Common/Lib/State.o )
[...]
Compiling Main             ( HasCASL/hacapa.hs,
HasCASL/hacapa.o )
Linking ...

real    6m0.739s
user    5m42.199s
sys     0m9.590s
maeder@turing:~/haskell/examples> ll a.out
HasCASL/PrintLe.o
-rwxr-xr-x  1 maeder wimi 4674747 2005-12-01 14:17 a.out
-rw-r--r--  1 maeder wimi   90308 2005-12-01 14:14
HasCASL/PrintLe.o
maeder@turing:~/haskell/examples> patch -p0
Common/Lib/Pretty.hs patch
patching file Common/Lib/Pretty.hs
Hunk #1 succeeded at 564 (offset -42 lines).
Hunk #2 succeeded at 609 (offset -42 lines).
maeder@turing:~/haskell/examples> time ghc -no-recomp
--make -O HasCASL/hacapa.hs
Chasing modules from: HasCASL/hacapa.hs
Compiling Common.Lib.State ( ./Common/Lib/State.hs,
./Common/Lib/State.o )
[...]
Compiling Main             ( HasCASL/hacapa.hs,
HasCASL/hacapa.o )
Linking ...

real    8m7.962s
user    7m46.492s
sys     0m12.345s
maeder@turing:~/haskell/examples> ll a.out
HasCASL/PrintLe.o
-rwxr-xr-x  1 maeder wimi 6470827 2005-12-01 14:42 a.out
-rw-r--r--  1 maeder wimi 2007272 2005-12-01 14:40
HasCASL/PrintLe.o

[simonpj]

Just to let you know, I can reproduce this problem nicely (thank you for setting up the repro case). It turns out to be caused by the simplifier's inlining policy which goes if not exponential then something very like it. It's made dramatically worse by the fact that $$ and <+> are left-associative. If you change them to right-assoc the problem disappears I think.

That's not an excuse -- the simplifier should not do this -- but it might be a useful workaround.

Simon

[simonpj]

Here are some follow-ups from Christian:

Thanks, for looking into it. For our code bloat, related to the ShATermConvertible instances, there are no associative operations. I've included the basic class and a few instances that pose no problem until very late in our final big binary (with many more instances).

Currently, I simply set "-fvia-C -O0" in parts of our code and hope that -optc-O1 helps a bit.

Cheers Christian

P.S. I've changed infixl to infixr

  infixr 6 <>
  infixr 6 <+>
  infixr 5 $$, $+$

The numbers are much better with infixr:

Linking ...

real    5m30.666s
user    4m56.950s
sys     0m9.262s
maeder@turing:~/haskell/examples> ll a.out HasCASL/PrintLe.o
-rwxr-xr-x  1 maeder wimi 4812378 2006-01-26 20:01 a.out
-rw-r--r--  1 maeder wimi  139828 2006-01-26 19:58 HasCASL/PrintLe.o

---

The code bloat goes away again when I now change back to infixl! Is this now a better patch for HughesPJ.hs?

Linking ...

real    5m18.860s
user    4m56.663s
sys     0m9.168s
maeder@turing:~/haskell/examples> ll a.out HasCASL/PrintLe.o
-rwxr-xr-x  1 maeder wimi 4808498 2006-01-26 20:23 a.out
-rw-r--r--  1 maeder wimi  140820 2006-01-26 20:21 HasCASL/PrintLe.o

Christian Maeder wrote:

When I also swap the corresponding equations the code bloat comes back:

> above_ p _ Empty = p
> above_ Empty _ q = q
> 
> beside_ p _ Empty = p
> beside_ Empty _ q = q
> 
> 
> Linking ...
> 
> real    7m10.727s
> user    6m25.456s
> sys     0m10.698s
> maeder@turing:~/haskell/examples> ll a.out HasCASL/PrintLe.o
> -rwxr-xr-x  1 maeder wimi 6213885 2006-01-26 20:11 a.out
> -rw-r--r--  1 maeder wimi 1762784 2006-01-26 20:09 HasCASL/PrintLe.o

[simonmar]

Reducing priority because (a) doesn't seem to happen much, and (b) we don't know how to fix it :-)

[simonmar]

This bug no longer happens with 6.12.1:

$ ghc --make HasCASL/hacapa.hs -O  
...
$ size HasCASL/hacapa
   text    data     bss     dec     hex filename
2231135  131492   12928 2375555  243f83 HasCASL/hacapa
$ ll HasCASL/hacapa
-rwxrwxr-x 1 simonmar simonmar 4051713 2009-12-18 19:34 HasCASL/hacapa*
$ patch -p0 Common/Lib/Pretty.hs <patch
patching file Common/Lib/Pretty.hs
Hunk #1 succeeded at 564 (offset -42 lines).
Hunk #2 succeeded at 614 (offset -42 lines).
$ ghc --make HasCASL/hacapa.hs -O
...
$ ll HasCASL/hacapa                      
-rwxrwxr-x 1 simonmar simonmar 4126044 2009-12-18 19:36 HasCASL/hacapa*
$ ll HasCASL/PrintLe.o 
-rw-rw-r-- 1 simonmar simonmar 115480 2009-12-18 19:36 HasCASL/PrintLe.o

Things get a little larger, but not in the massive way reported in the ticket. So, I assume this is now fixed.