• Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> May 29 2014

Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:

On Thu, 29 May 2014 09:16:26 -0700
"H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> wrote:

 On Thu, May 29, 2014 at 01:13:39PM -0300, Ary Borenszweig via
 Digitalmars-d wrote:
 On 5/29/14, 12:22 PM, Steven Schveighoffer wrote:
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.


 If you add reference counting or a GC to the compiler, it will make
 those large projects compile, but it will inevitably be slower than
 now. That's why Walter disabled GC completely in the compiler
 (turning it on made the compiler really slow).

 I think the right steps are:

 1. Enable some kind of GC
 2. Profile and see where are the bottlenecks.
 3. Optimize those cases.
 4. Go to 2.


 Shouldn't be as simple as a compiler switch to enable compile-time GC?


The compiler has a GC in it already. It's just that it's disabled, because
enabling it seriously slowed down compilation What we should probably do is
simply make it so that the compiler uses a GC when it actually runs out of
memory but otherwise makes no attempt at deallocation. That way, it's
efficient for normal compilation, and the programs that run out of memory
while compiling can still be compiled.

- Jonathan M Davis