Tracy Profiler Integration
avrina12309412342 at gmail.com
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
> 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.
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