Ref counting for CTFE?
Steven Schveighoffer via Digitalmars-d
digitalmars-d at puremagic.com
Thu May 29 08:22:54 PDT 2014
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
More information about the Digitalmars-d
mailing list