On Thursday, 29 May 2014 at 15:22:54 UTC, 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.
It was during my talk. I have mentioned experience of Etienne
(etcimon) when building ASN.1 parser using Pegged which was
impossible to compile unless you did all code generation in
separate run from actual project compilation.
I have talked about it with Don and he says that many CTFE memory
allocation issues can be fixed without any GC by simply improving
interpreter implementation. For example, incrementing an integer
allocates new instance right now AFAIR. But he is very unlikely
to work on it personally in any near future.
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'd love to see command-line flag that enables garbage collection
in compiler (disabled by default). It does not matter how fast
compiler is if it crashes on big project. And difference between
10 seconds vs 30 seconds is not as important as difference
between 2 seconds vs 10 seconds anyway.
