Compiling to Heap for CTFE

[Don Clugston]

Craig Black wrote:
> Currently, CTFE only supports a subset of the language, and it relies on 
> the compiler acting as an interpreter, which is slow.

I'm encountering some severe slowdowns through CTFE; I've had to optimise my 
CTFE code for speed. Interestingly, at the present time, the interpreter doesn't 
seem to be the problem. The real problem is that DMD doesn't seem to release 
CTFE memory properly. For example, when you change an element of a string, AFACT 
it creates a new string and NEVER deletes the original! So at present, CTFE 
optimisation is about minimising the number of variables created or modified, 
rather than minimising the number of operations.


   It just occured
> to me that if we could compile code to the heap, there would be no need 
> for a CTFE interpreter.  CTFE code could be compiled to the heap and 
> executed at full speed.  Further, all the features of D would be 
> available at compile time.
> 
> Thoughts?

In my code, the CTFE is normally heavily templated; it's rare that the same code 
is run multiple times, so compilation wouldn't help much. And we probably don't 
want to allow arbitrary code to run at compile-time (try detecting a virus that 
only exists in source-code format!)

Some simple suggestions that would be major leaps forward in practical CTFE 
programming are:
* gc at compile time, to stop the symbol table getting clogged up.
* some version statement to detect if you are in CTFE. This would mean
   (a) you could create CTFE-able versions of code that uses (for example) asm 
at run-time; and far more importantly:
  (b) you could insert printf/writefln statements in the non-CTFE version, for 
assistance with debugging.