From: Michael Hope <michaelh@ju...> - 2001-10-06 23:50:46
I've started looking at doing a new release of gbdk (first in a year.
Sigh). I've done a few optimisations and fixes to help speed things up
and bring down the memory footprint. They are:
1. Optimise the most used bit vector functions.
2. Fix all leaks in SDCCpeeph.c
3. Change the restart logic in SDCCpeep.h to re-run instead of restart.
4. Added allocation tracing support.
5. Re-added support for optionally using libgc, the garbage collector.
(1) cut a 25s compile to 15s. (2) allowed gbdk's dscan.c to compile in
60MB of memory instead of failing in ~250MB. The peephole routines create
a new hash table on each line of each rule, which leaks like crazy on big
functions. (3) changes the 'restart' logic to re-run once all rules have
had a go instead of restarting immediatly. This cuts dscans compilation
from 100s to 12s. I don't see any side effects in it. (5) cuts the
footprint from 60MB to 20MB - try --enable-libgc.
(4) is the most interesting IMHO. It is a mid level between gc and having
to pedantically free(). Basically you can do this:
void *p = traceAlloc(&traceCtx, Safe_alloc(5))
as many times as you want, and then at some time later call
to free all the memory. This is useful in 'steady state' functions such
as the code generator where you know nothing that you allocated is still
used at the end of the fun. It is in use in the peehole code and the z80
generator, but makes no real difference to the 60MZB footprint.
I've also added Safe_free and Safe_strdup to fit in with the libgc
support. Please use these instead of free() and strdup().