Tracy Profiler Integration

[Steven Schveighoffer]

On 8/4/20 12:01 PM, Avrina wrote:
> On Tuesday, 4 August 2020 at 12:47:54 UTC, Steven Schveighoffer wrote:
>> On 8/4/20 4:44 AM, Stefan Koch wrote:
>>> newCTFE in the end, has a lot less benefit than I first assumed.
>>
>> If CTFE becomes way less expensive (in CPU usage and memory usage), 
>> then the template problem becomes easier as well, as we can do more 
>> CTFE to replace templates.
> 
> CTFE takes 500 ms for my project. It takes a total of about 10 seconds 
> for the frontend to do everything, without -inline. The more significant 
> problem is definitely templates, their expansion and how everything is 
> processed back into a AST. Such as the case if your run CTFE, even 
> "newCTFE" the result is still going to have to be expanded back into an 
> AST, which is the core problem.

I have faced much different problems (mostly with memory consumption). 
Part of the problem of current CTFE is that it consumes lots of memory 
needlessly (at least that's my recollection). That is part (but not all) 
of the reason we use recursive templates instead of CTFE to solve our 
compile-time computation problems.

I don't know whether newCTFE fixes ALL the problems or not. But it will 
still help.

> 
>>> If I had had a good integrated profiler back then, and some of the 
>>> code which I have access to now, I would probably never have started 
>>> newCTFE, and would have tried to fix the template system itself.
>>
>> I still think newCTFE has worthwhile benefit, even if it alone cannot 
>> fix all the problems.
>>
>> I think newCTFE and type functions (along with Manu's ... DIP) would 
>> be a good combination to attack the problem.
>>
> 
> It doesn't help, it just introduces a whole lot of more complexity into 
> the compiler as well. Effectively it creates a second compiler within 
> the compiler. It is much more complicated than the current solution, and 
> I don't imagine the speed up is going to be that much as, for my case it 
> will only be able to reduce the build time by a maximum of 500 ms.

What is "It" that you are talking about?

I imagine part of the problem here is that CTFE is avoided because it 
doesn't deal with types and compile-time lists very well -- you have 
only one solution there. In which case, CTFE is not used in many places 
where it really is a natural fit.

So really, if CTFE was more usable, it could replace the vast template 
usage that is likely causing your build to be slower, and then an 
optimized CTFE becomes more relevant.

-Steve