I'm looking for ways to figure out what parts of the code slows down the compiler other than brute force trial.

Can I use -vtemplates switch for this?
Would -v (verbose) switch helpful in some way?
How would I know if my bottleneck is ctfe or templates?
How do the compiler devs approach this issue?

I'm interested in all kinds of tricks to the point of debugging the compiler itself although anything less complicated would be appreciated.

On Saturday, 30 January 2021 at 22:47:39 UTC, Ahmet Sait wrote:
> I'm looking for ways to figure out what parts of the code slows down the compiler other than brute force trial.
>
> Can I use -vtemplates switch for this?
> Would -v (verbose) switch helpful in some way?
> How would I know if my bottleneck is ctfe or templates?
> How do the compiler devs approach this issue?
>
> I'm interested in all kinds of tricks to the point of debugging the compiler itself although anything less complicated would be appreciated.

I have a way of getting the profile data your are after.
Get the dmd_tracing_20942 branch from https://github.com/UplinkCoder/dmd
Compile that version of dmd.
this special version of dmd will generate a trace file which can be read with the included printTraceHeader tool

On Saturday, 30 January 2021 at 23:34:50 UTC, Stefan Koch wrote:
> 
> this special version of dmd will generate a trace file which can be read with the included printTraceHeader tool

you will want to take a look at the PhaseHist command which shows you the compiler phase that took the most time.

Alternative I recommend using callgrind to profile where dmd spents most of it's time.
For that to be useful you need a debug build of dmd though.

On Saturday, 30 January 2021 at 23:34:50 UTC, Stefan Koch wrote:
> On Saturday, 30 January 2021 at 22:47:39 UTC, Ahmet Sait wrote:
>> [...]
>
> I have a way of getting the profile data your are after.
> Get the dmd_tracing_20942 branch from https://github.com/UplinkCoder/dmd
> Compile that version of dmd.
> this special version of dmd will generate a trace file which can be read with the included printTraceHeader tool

Interesting. Is this something that we could get into dmd with a switch? 🤔

On Sunday, 31 January 2021 at 12:16:50 UTC, Imperatorn wrote:
> On Saturday, 30 January 2021 at 23:34:50 UTC, Stefan Koch wrote:
>> On Saturday, 30 January 2021 at 22:47:39 UTC, Ahmet Sait wrote:
>>> [...]
>>
>> I have a way of getting the profile data your are after.
>> Get the dmd_tracing_20942 branch from https://github.com/UplinkCoder/dmd
>> Compile that version of dmd.
>> this special version of dmd will generate a trace file which can be read with the included printTraceHeader tool
>
> Interesting. Is this something that we could get into dmd with a switch? 🤔

Try LDC 1.25 (now in beta testing) with --ftime-trace. Clang has the same option, so you can read more about it online in that context. Be sure to check out the related commandline flags.
I recommend the Tracy UI to look at traces, because it is by far the fastest viewer of large traces. https://github.com/wolfpld/tracy

-Johan

On Sunday, 31 January 2021 at 12:31:59 UTC, Johan Engelen wrote:
> On Sunday, 31 January 2021 at 12:16:50 UTC, Imperatorn wrote:
>> On Saturday, 30 January 2021 at 23:34:50 UTC, Stefan Koch wrote:
>>> [...]
>>
>> Interesting. Is this something that we could get into dmd with a switch? 🤔
>
> Try LDC 1.25 (now in beta testing) with --ftime-trace. Clang has the same option, so you can read more about it online in that context. Be sure to check out the related commandline flags.
> I recommend the Tracy UI to look at traces, because it is by far the fastest viewer of large traces. https://github.com/wolfpld/tracy
>
> -Johan

Cool, will take a look 👍

On Sunday, 31 January 2021 at 12:31:59 UTC, Johan Engelen wrote:
> Try LDC 1.25 (now in beta testing) with --ftime-trace. Clang has the same option, so you can read more about it online in that context. Be sure to check out the related commandline flags.
> I recommend the Tracy UI to look at traces, because it is by far the fastest viewer of large traces. https://github.com/wolfpld/tracy
>
> -Johan

Does ldc produce traces in a format that Tracy supports? I can't seem to open the generated *.time-trace files with it. (tracy 0.7.5-1 installed from Arch Linux AUR.)

On Sunday, 31 January 2021 at 16:13:24 UTC, Anonymouse wrote:
> On Sunday, 31 January 2021 at 12:31:59 UTC, Johan Engelen wrote:
>> Try LDC 1.25 (now in beta testing) with --ftime-trace. Clang has the same option, so you can read more about it online in that context. Be sure to check out the related commandline flags.
>> I recommend the Tracy UI to look at traces, because it is by far the fastest viewer of large traces. https://github.com/wolfpld/tracy
>>
>> -Johan
>
> Does ldc produce traces in a format that Tracy supports? I can't seem to open the generated *.time-trace files with it. (tracy 0.7.5-1 installed from Arch Linux AUR.)

Use the 'import-chrome' tool bundled in Tracy to convert it.

On Sunday, 31 January 2021 at 16:39:12 UTC, Boris Carvajal wrote:
> On Sunday, 31 January 2021 at 16:13:24 UTC, Anonymouse wrote:
>> Does ldc produce traces in a format that Tracy supports? I can't seem to open the generated *.time-trace files with it. (tracy 0.7.5-1 installed from Arch Linux AUR.)
>
> Use the 'import-chrome' tool bundled in Tracy to convert it.

Indeed. It's a little annoying that you will see many horizontal 'traces' in tracy and probably will have to scroll all the way down to see the actual LDC trace.
It's a tradeoff I made between nicely displayed trace block names, vs. using only a few categories... Maybe other people can chime in a figure out a better way of outputting the trace item names (we are using LLVM functionality here btw).

-Johan