Build time/costs

[Stefan Koch]

On Tuesday, 11 December 2018 at 06:15:45 UTC, Manu wrote:
> So, I know people have studied this, but I can't find any 
> evidence of
> concise collated data.
> I don't know how to implement CT range logic efficiently.
> There are 3 competing strategues:
> - recursive template expansion (including staticMap)
> - static foreach, which may require a fail-test suffix if no 
> iteration
> of the loop assigned the template
> - CTFE foreach
>
> Which is preferable, and for what counts of elements?
> I think conventional wisdom is that CTFE is always superior? Is 
> that
> true? *always*?
> Is there any CTFE overhead on small datasets (ie, 0-2 elements).
> Is there overhead in the case where you might need to coerce a 
> tuple
> into a runtime array for looping on by surrounding it in `[ tup 
> ]`?

Alright, let me answer those first, once newCTFE lands and runs 
with it's own x86 jit, it _will_ be the fastest path. Except for 
verly simple loops with up to 5 iterations, where the jit 
overhead will dominate, however even in that case the overhead 
will be very small, compared to the alternatives.

> What about static foreach? Is it superior to CTFE foreach in 
> the limited places where it's applicable, but where either 
> could be chosen?

static foreach is genrally slow, and without clever decision 
logic and proper integration with newCTFE it is very likely that 
it won't improve.
However when iterating over type-tuples it is pretty much the 
only option.

> We need reliable best-practises.
>
> On a tangent, I think D would really benefit from C++11's `...`
> expression; which applies a static-map in-language without any
> recursive template expansions or other workarounds, and with a 
> much
> improved readability.
> That expression could replace basically every application of 
> static
> operation on lists extremely efficiently... has it been rejected
> already? Why?

one reason could be that ... expressions look ugly.
And as soon as newCTFE lands the performance problems will not be 
an issue.

Regards,

Stefan