New blog post on the cost of compile time

[max haughton]

On Monday, 16 January 2023 at 09:12:59 UTC, FeepingCreature wrote:
> On Monday, 16 January 2023 at 04:30:25 UTC, Steven 
> Schveighoffer wrote:
>> In this post: 
>> https://forum.dlang.org/post/tm3p0p$2js2$1@digitalmars.com
>>
>> I mentioned:
>>
>>> I did a test on something I was working on for my talk, and 
>>> I'm going to write a blog post about it, because I'm kind of 
>>> stunned at the results.
>>
>> Well, I finally got around to it:
>>
>> https://www.schveiguy.com/blog/2023/01/the-cost-of-compile-time-in-d/
>>
>> Let me know what you think.
>>
>> -Steve
>
> Looks like :handwaves: given a 2.4Ghz processor, that'd be 150k 
> cycles per ReturnType instantiation? Not super much, but not 
> nothing either. If that distributes over five templates, it'd 
> be something like 30k for a template instantiation in general. 
> For something that hits the allocator a few times, that seems 
> ... about right?
>

Processors these days are both faster than that and have pretty 
good IPC compiling D code so it's worse.

> Indicating to me that if we want this to be fast, we have to 
> find a way to make a template instantiation *do less.* I think 
> that's gonna be a hard sell, given that the instantiation 
> absolutely has to make a copy of the entire template body AST 
> given the compiler design as it is.

A lot of these copies are made defensively — some of them are 
actually required, or at least require a different theoretical 
model of compilation to be avoided, whereas others are basically 
just made to avoid mutating the original AST. Some of this just 
boils down to not having a const-first attitude, other things are 
harder.

Making more things const makes avoiding these copies easier. I 
was fiddling around with a dmd patch that automatically spits out 
a diff that adds const to things where it can.

> Looking at a profiler, how would you say these cycles are 
> distributed between "copy tree" and "walk tree for semantic"?

A *lot* of dmd compilation is spent doing memcpy. However I think 
it's actually mostly caused by CTFE arrays being shunted around.

The thing to do for those arrays is probably to refcount them so 
the copy on write can be done in place for the hopefully common 
case.