D is supposed to compile fast.

[Chris Katko]

On Saturday, 24 November 2018 at 20:44:57 UTC, welkam wrote:
> On Friday, 23 November 2018 at 08:57:57 UTC, Chris Katko wrote:
>> D is supposed to compile fast.
>
> You didnt read the fine print. It compiles simple code fast. 
> Also compilation is separate step from linking and your program 
> might spend half of "compilation" time in link phase.

Wait wait wait wait wait.

So 1) I have to compile manually, then link. Except that also 
runs the files every time even if they're up-to-date. Is that 
normal behavior for C/C++?

Two questions/topics/issues:

-------------------------------------------------------

#1 How to I only build files that are dirty? Do I actually need a 
build program like DUB, MAKE, or CMAKE to do that? (Can make, 
cmake be used?) How do they recognize files are out-dated if DMD 
can't? Is that just an industry-standard 
specialization/separation-of-responsibilities to not have the 
compiler auto-detect up-to-date builds?



I have the simplest project ever. Less than 10 files and my 
non-VStudio build-scripts have always been simple. A few lines or 
one long line running GCC/Clang/etc. I don't want to learn a make 
program's huge syntax just to compile a program if I can avoid 
it! (I've still got so many D and networking topics to learn on 
the back-burner!)

I've heard "just use dub" but I've also heard that dub have 
flaws/gotchas that I can't remember when it comes to say, dynamic 
linking DLLs/SOs. So I've been hesitant to learn it.




#2 I ran individual file times. They're pretty shocking.
-------------------------------------------------------

std.regex is still, the Devil (TM), clocking in at almost FOUR 
SECONDS for a very simple set of code that simply matches lines 
for a poor-man's INI file parser (with a custom feature that 
allows tab indents to be nested sections). I was considering 
ripping it out and replacing it with JSON and this has REALLY 
motivated me to rip out the regex.

Here's the file times:

novous at saturn:~/Desktop/bitbucket/ss14$ time dmd -c molto.d
Class 4 - Scaled Rotated
hello
hello -- it matches!

real	0m0.377s
user	0m0.344s
sys	0m0.028s
novous at saturn:~/Desktop/bitbucket/ss14$ time dmd -c helper.d

real	0m0.118s
user	0m0.096s
sys	0m0.020s
novous at saturn:~/Desktop/bitbucket/ss14$ time dmd -c editor.d

real	0m0.626s
user	0m0.536s
sys	0m0.072s
novous at saturn:~/Desktop/bitbucket/ss14$ time dmd -c common.d

real	0m0.755s
user	0m0.636s
sys	0m0.092s
novous at saturn:~/Desktop/bitbucket/ss14$ time dmd -c map.d

real	0m1.045s
user	0m0.904s
sys	0m0.112s
novous at saturn:~/Desktop/bitbucket/ss14$ time dmd -c object_t.d

real	0m0.359s
user	0m0.336s
sys	0m0.024s
novous at saturn:~/Desktop/bitbucket/ss14$ time dmd -c animation.d

real	0m0.365s
user	0m0.280s
sys	0m0.068s
novous at saturn:~/Desktop/bitbucket/ss14$ time dmd -c ini.d

real	0m3.672s <--- WOWZA
user	0m3.292s
sys	0m0.332s



I have to tell you that, as an outsider (who is VERY interested 
in D), this is very frustrating. "Compile times are fast" != 
"build times" is a huge misconception that borders on being a 
clever lie or twisting of words. When people hear "compile 
times", they think "time to compile the whole project" not "time 
to compile a simple test case that doesn't use any typical D 
features--also, it's not linking." Second, as shown here, it's 
not fast even for compiling! Because the second you touch 
std.regex (which has NO WARNINGS in the documentation), you're 
greeted with another clever lie-by-omission: a 10x explosion of 
build time over some modules.

Now let's stop for a moment. I'm not accusing anyone, and "lie" 
is a strong word with heavy guilt implications--like people are 
intentionally being very sneaky to deceive new-comers. I'm not 
saying any of that, so you can relax and put down the pitchfork. 
I'm not attacking you or your group personally. However, I can't 
think of any better word.

So my point is, I keep running into either misconceptions that 
conveniently make D look good, and other gotchas with NO 
DOCUMENTATION that make the language much slower to work with 
than expected.

And if I'm experiencing this, there are dozens (hundreds?) who 
hit the same roadblocks and gotchas and many people are much less 
forgiving/understanding than I am and simply just "give up" 
without ever telling you. So I'm trying to say this with the best 
of intentions. You can't have standard modules with no warning 
documentation that explode your RAM usage and compile times 
orders-of-a-magnitude more than other ones. You can have an 
"alpha" or "beta" or "Addon" or "external" module. But putting it 
in your standard framework implies that it works well with the 
other modules (::cough::std.variant and threads::cough::), and 
that it's not incredibly slower or more resource intensive. 
Having it in your standard library implies it meets a certain 
_STANDARD_.

I mean, can you think of any module in the Python/Javascript/C# 
standard library that simply including it will swell your program 
to the point it can't compile? I'm not an omnipotent master 
programmer, but as a professional, I can't recall ever having 
this situation in another library or language.

And it's very frustrating for someone who _wants_ to learn and 
use D.

Thank you for your time, and I hope you had a great Thanksgiving.