Implementing and optimizing a simple graph metric

[Joseph Rushton Wakeling]

On Wednesday, 18 September 2013 at 15:22:51 UTC, bearophile wrote:
> Joseph Rushton Wakeling:
>
>> I haven't yet tried alloca or other manual memory management 
>> -- I felt a bit resistant to this as I'd prefer to keep the 
>> code simple and readable -- but I'll give that a go too just 
>> to see how it goes.
>
> I'd like some stack-allocated variable-length array in 
> D+Phobos, as in C++14. It's also a basis to build several other 
> stack-allocated data structures.

Yes, that'd be useful, although in the case of this code I think 
that stack vs. heap probably isn't that important.  If the data 
is small enough for stack allocation, the calculation will be 
quick anyway.

>> However, my impression now is that having or not having it, or 
>> any other method (e.g. enum T0, T1, etc.) makes absolutely no 
>> difference, and that I might as well be simple and write 0 for 
>> integral-types, 0.0 for floating-point.
>
> Right. And this could be right even if you want T=Rational.

Actually, on re-testing this just now, I'm returning to my 
original view.  I find that if you put in raw floating-point 
numbers like 0.0, 1.0 etc. the resulting code can be slower in 
the case where T = float.  Putting to!T or using enums as you 
suggest appears to make no difference.

This is a guess rather than confirmed by looking at assembly, but 
I'm presuming that to!T(0) and other conversions of compile-time 
constants are evaluated at compile time, so you don't in practice 
carry the cost you'd normally get from using to().