Ref counting for CTFE?

[Steven Schveighoffer via Digitalmars-d]

One subject that frequented the talks at dconf was the poor performance of  
CTFE and mixins.

The major issue as I understand it (maybe I'm wrong) is the vast amounts  
of memory the compiler consumes while building mixin strings. In fact, one  
of the talks (can't remember which one) mentioned that someone had to  
build their project in steps so the compiler did not crash from OOM.

In CTFE, we are not constrained by the runtime GC, and in fact, we have no  
GC at this point (it's disabled). What about implementing rudimentary,  
possibly slow but correct, reference counting for CTFE allocated data? It  
doesn't have to be perfect, but something that prevents consumption of GB  
of memory to compile a project may make the difference between actually  
compiling a project and not. It would also be a nice little confined  
environment to try out ref counting + GC for cycles.

As a side note, I find it weird that the compiler has given up freeing  
memory, EVER, in order to achieve speed. Sure, the killing of the process  
will act as the ultimate GC, but when it is killed before the process is  
done compiling, the time it takes to compile approaches infinity. And when  
the computer helpfully starts swapping to avoid killing the process,  
things aren't much better.

I understand compiler speed is really important. But it's not worth much  
if the speed comes at the cost of ACTUALLY COMPILING.

It reminds me of the tango.xml accolades. Not everyone realizes that it  
only works on a fully memory-loaded XML file. Sure, it's fast after that,  
but you can't just discount the time it takes to load (or the memory  
required!)

-Steve