Are these bencmarks recent and real?

[Chris Katko]

On Monday, 30 August 2021 at 15:34:13 UTC, jfondren wrote:
> On Monday, 30 August 2021 at 13:12:09 UTC, rempas wrote:
>> Just trying to compile a sample basic gtk-d project (including 
>> the libraries themselves) using ldc2 and optimization "-Os" 
>> and seeing how much time this takes, I want to ask if the 
>> benchmarks found 
>> [here](https://github.com/nordlow/compiler-benchmark) about 
>> ldc2 are real. Again seeing the gtk-d project taking so much 
>> time, It's hard to believe that ldc2 compiles faster that tcc 
>> and go. However, this test probably doesn't use optimizations 
>> but still.... Ayn thoughts?
>
> You can see how recent they are, and yeah they're real, but 
> it's a very specific artificial benchmark and there's a lot 
> more to say about compilation speeds about the various 
> languages. That D can compile amazingly fast can be shown just 
> by building dmd itself. But unlike go, D also gives you a bunch 
> of tools that you can use to make compile times take a lot 
> longer. Likewise you could say that D can make just as careful 
> use of memory as a C program, but that D unlike C also gives 
> you a bunch of tools that you can put towards much less careful 
> use of memory.

One definite flaw I've had with D's ecosystem, is these issues 
aren't made CLEAR. Like if you dare import regex and use a single 
regex match, your compile time explodes by 10-15 seconds on my i3 
chromebook (from ~3 seconds to over 15!).

There are a lot of gotchas in D. Anything that "can" explode your 
program in terms of memory leaks, or run / compile-time 
performance should be clearly documented.

And the barrier-to-entry is annoying even to fix documentation. I 
went to a D page, clicked "improve this page" and I have to... 
fork the repo, and then submit a pull request. Even if if's just 
to correct a typo. Is that kind of lock-and-key audited security 
over edits to documentation... really necessary? If it takes more 
than 10 seconds, most people aren't even going to bother.