[Dctc-general] lowering memory consumption during compilation

[Grzegorz B. Prokopski]

Hi Eric!

For my old computer 650MB to compile dc_gui is barely beareable :-(
I tried to figure out what gcc does, which is SO expensive on memory.
After some experimentation I figured out that these are:
-fschedule-insns -fschedule-insns2
(in fact the first one is giving the problems but second one depends on
the first so it'd turned off anyway...)
They are turned on by default when you compile w/ -O2.

My last experiences with other software showed that on many, especially
non-intel architectures this option might be dangerous:
 -fstrict-aliasing 
It does some analysis of the way code is constructed but as some serious
compiler people w/ PhD told me - because of how C does things - these
analysis can almost never be 100% sure. So it's safe to just turn it off
(and I've seen many, many projects do).

There's some penalty in turning off -fschedule-insns. On another project
for which at some point I wanted to turn it off - I measured that it
gave ~10% worse performance with -fno-schedule-insns. Therefore there's
no "silver bullet". Either we choose reasonable memory consumption
during one-time compilation but slightly slower app, or the opposite.

To configure.in in Debian Package I added:
dnl *** turn off 1) dangerous optimizations 2) memory consuming
optimizations
CFLAGS="$CFLAGS -fno-strict-aliasing -fno-schedule-insns
-fno-schedule-insns2"

You might want to:
0) add -fno-strict-aliasing to be used always (safety)
1) make -fno-shedule-insns a configure option
(--enable-low-mem-compilation)
2) make -fno-shedule-insns only apply to compilation of interface.c.

Now I gcc takes less than 60MB virtual mem and I can "just compile"
dc_gui, w/o closing all of the programs, praying so that it didn't
exceed the available virtual memory anyway and w/o hearing swap
working hard for long minutes while real CPU usage by gcc is ~2%.

HTH

                                        Grzegorz B. Prokopski

PS: I must say the latest version is huge improvement over previous,
where I had a number of serious problems making it hardly usable.
Good to see bugs squashed effectively :-)

[I still reserve the right to submit bugreports though ;-]]

-- 
Grzegorz B. Prokopski <address@hidden>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM