Tracy Profiler Integration

Stefan Koch uplink.coder at googlemail.com
Tue Aug 4 16:11:38 UTC 2020


On Tuesday, 4 August 2020 at 16:01:54 UTC, 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.
>
It's not quite that AST insertion is slow. It's the fact that you
have to do semantic processing piece by piece, which is expensive.
If you have completely semantically processed nodes, linking them
into the tree is quite painless.
>
> 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 exactly do you mean.
type functions are a relatively simple extension of ctfe.

"..." is a little more involved but also not massively 
complicated.
both should stay under 1000 lines when implemented
*fingers crossed*


More information about the Digitalmars-d mailing list