Tracy Profiler Integration

Avrina avrina12309412342 at
Tue Aug 4 16:01:54 UTC 2020

On Tuesday, 4 August 2020 at 12:47:54 UTC, Steven Schveighoffer 
> 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.

>> 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.
> -Steve

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.

More information about the Digitalmars-d mailing list