CTFE slower than expected

[Don Clugston]

On 29/05/12 12:25, Manu wrote:
> I've been trying to work out why my compile times have gone to hell
> recently.
>
> I have a lib, it takes 3.5 seconds to compile.
> I add one CTFE heavy module, it's not huge, certainly much smaller than
> the rest of the app, and it blows out to 18 seconds. I've done some
> experiments removing bits and pieces of code, I can isolate the bits
> that add seconds to the compile time, but the big offenders are one-line
> mixins which use CTFE fairly aggressively to generate the strings they
> mix in.

>
> Can anyone comment on CTFE as implemented? Why is it so slow?

You really don't want to know. What it's actually doing is horrific. Bug 
6498.

The reason why it's still like that is that CTFE bugs have kept cropping 
up (mostly related to pointers and especially AAs), which have prevented 
me from doing anything on the performance issue.

> It's
> certainly not executing a lot of code. I can imagine executing the same
> routine in an interpreted language like lua would take milliseconds or
> less, not multiple seconds.
> What are the bottlenecks?

It's was originally based on the const-folding code used by the 
optimizer. So most of the code was written with totally goals (that 
didn't include performance).

> Is there any way to improve it?

Oh yeah. Orders of magnitude, easily. The slowness is not in any way 
inherent to CTFE. The experience will be completely different, once I 
have some time to work on it -- I know exactly how to do it.