On Mon, Nov 28, 2022 at 04:27:03AM +0000, Basile B. via Digitalmars-d wrote: [...]
> For better compile times and with LDC people should also always use the undocumented option `--disable-verify` (for a DUB recipe this would go in the dlags-ldc2 array for example).
> 
> By default ldc2 verifies the IR produced but that verification is mostly useful to detect bugs in the AST to IR translation, so unlikely to detected any problems for a project like LDC, that's well settled, and has the main drawback to be very slow, especially with functions with bad a cyclomatic complexity. For example for my old iz library, 12KSLOCs of D (per D-Scanner critetions), the gain measured with `--disable-verify` goes from 150 to 300ms, depending on the run.

Hmm.  I just tested `--disable-verify` on one of my medium-complexity projects (just under 40 .d files, compiled in a single command); didn't measure any significant speed difference.  Both with and without `--disable-verify` it took about 20 seconds for a full build (generate Linux & Windows executables + run unittests).


T

-- 
Javascript is what you use to allow third party programs you don't know anything about and doing you know not what to run on your computer. -- Charles Hixson

On 28/11/2022 5:38 AM, rikki cattermole wrote:
> So what is interesting about this is MSVC link is taking about ~15s by itself, LLVM is 15s which means that the frontend is actually taking only like 1s at most.

Very interestingly it is indeed not 15s at all, but ~4s.

Thanks to the nifty /TIME switch on MSVC link! Welp, guess something else is doing it.

On 29/11/2022 9:12 AM, rikki cattermole wrote:
> On 28/11/2022 5:38 AM, rikki cattermole wrote:
>> So what is interesting about this is MSVC link is taking about ~15s by itself, LLVM is 15s which means that the frontend is actually taking only like 1s at most.
> 
> Very interestingly it is indeed not 15s at all, but ~4s.
> 
> Thanks to the nifty /TIME switch on MSVC link! Welp, guess something else is doing it.

LDC is doing a full link each time, while with incremental linking you can get this far lower (like dmd is doing), which is not accurate unfortunately. If you did use incremental linking you unfortunately must remove the extra unused import libraries that LDC is adding (which don't make enough of a difference to matter with a full link.

TLDR: LDC is correct, DMD is giving not entirely correct results. But there should be some wins here if different choices were made.

On 11/27/2022 8:12 AM, Steven Schveighoffer wrote:
> Phobos does not make this easy either. Things like std.format are so insanely complex because you can just reach for a bunch of sub-templates. It's easy to write the code, but it increases compile times significantly.

I once tracked just what was being instantiated to format an integer into a string. The layers of templates are literally 10 deep. One template forwards to the next, which forwards to the next, which forwards to the next, 10 layers deep.

This is not D's fault. It's poor design of the conversion code.


> I still have some hope that there are ways to decrease the template cost that will just improve performance across the board. Maybe that needs a new frontend compiler, I don't know.

Phobos2 needs to take a hard look at all the template forwarding going on.

I've also noticed that many templates can be replaced with 2 or 3 ordinary function overloads.

Early into my initial scoping of value type exceptions, I looked into std.format.

There is no reason formattedWrite should allocate right? So why isn't it already working with -betterC.

Well, the answer is quite simple, sooooo many exceptions are strewn throughout ready to be fired off. I kinda gave up any hope that it could ever be usable in even the harshest of scenarios.

But if we are thinking about doing a full rewrite of it, it would certainly be good to ditch the class based exception mechanism for error handling!